Pull to refresh

Comments 160

Если не сложно напишите историю развития самой платформы, кто и когда начал её пилить. И второе — опишите Ваше мнение по поводу развития платформы, какую архитектуру считаете наиболее перспективной.
Спасибо за статью, давно хотелось узнать подробности, простота и функционал 7-ки всегда поражали, 8-ка немного потеряла в простоте на мой взгляд, но я не 1С-ник ))
Реально было бы узнать про мобильную платформу, а именно — тонкости реализации на Android, iOS и WinPhone.
Например, на сколько сильно вообще они отличаются структурно, и какая дальше будет спираль их развития.
Стационарная платформа — максимально идентична что под линукс, что под виндовс. Но с мобильными такой финт не прокатит, как же вы собираетесь решать вот эти вопросы.

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

Вот именно сама суть развития какая планируется, с какими реальными проблемами столкнулись и как решили, или не решили.

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

З.Ы. Статья, как вводная — интересна. Но методы применения внешних библиотек с примером кусков кода — мне кажется тут не к месту, всем понятно, что 1С не сможет разгласить именно реально интересные куски кода и методы решения. Но вот если бы вы делились именно опытом разработки, т.е. применения тех или иных вещей — было бы круто.
Например, почему выбрали именно эту библиотеку, а не другую.
Для мобильной платформы тоже реализуется принцип идентичности: Андроид, яОсь и Винда предоставляют примерно одинаковые возможности, с точностью до ограничений конкретной платформы. Платформа для мобильной Винда немного не показатель, она еще в слишком юном возрасте :)
Но, например, работа с пушами и локальными уведомлениями есть и для Андроида и для яОси. А для упрощения работы — предоставляется еще и специальный промежуточный интерфейс, чтобы сделать работу с пушами на яОси более пригодной для использования с платформой.
Клиент на мобильном устройстве — это понятное желание. Оно нами понимаемо и обдумываемо регулярно.
Но «можно сделать все, однако нельзя сделать всего» :)
Для мобильной платформы тоже реализуется принцип идентичности: Андроид, яОсь и Винда

До версии 8.3.5 — так и было, а вот после нее, все пошло по другому пути. Вы почитайте сколько всего не доступно на iOS, часть из-за технической реализации, вторая часть — из-за лицензионных ограничений AppStore и т.д.
Я про это говорил.
Так я вроде изначально об этом говорил, когда писал «с точностью до ограничений конкретной платформы» (наверное было некорректно использовать тут термин «платформа», тут не правильнее написать «конкретной мобильной ОС»).
Мы не можем обходить требования каждого вендора, иначе никогда в магазины не попадем.
Из какого-то особого различия сходу видится только печать и невозможность управлять качеством фото/видео на яОс.
Или вы о чем-то другом говорите?
Ну вот это и интересует. Т.е. вот смотрите — в платформе сделали поддержку пушей (и на дроиде и на иосе), но вот работа с интентами — это чисто явление андроида, и его таки реализовали, в «ущерб» возможностей iOS, но вот в андроиде есть еще одна замечательная функция — бродкасты. Вот их почему то не сделали, и сейчас приходится добиваться этого функционала костылями.

Вот и вопросы отсюда — планируется ли сделать бродкасты? Видь они (или ближайшие аналоги, скажем так) отличаются от ОС к ОС.

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

Вот именно такие вопросы интересуют, видь этот функционал можно реализовать на каждой из ОС, но принцип реализации там значительно отличаться будет. Отсюда и вопрос — планируется ли такой функционал? Если нет, то все понятно. А если да — то вот тут мне кажется тема для отдельной статьи на хабре :)
Чтобы реализовать ту или иную возможность — над понимать, зачем она нужна. Причем не абстрактно, как разработчику универсальному, который старается использовать все возможности мобильной ОС, а с точки зрения потребностей разработчика бизнес-приложений. Ведь платформа является в первую очередь системой разработки бизнес-приложений.
Если у вас есть примеры того, для решения каких задач вам нужны броадкасты или какие-то другие возможности мобильных платформ — это надо до нас разными способами доносить. Т.е. интеграция интересует в первую очередь с этой точки зрения.
ЗЫ: А как 1С узнает, в каком формате счет в pdf? ;)
По первой части — написал в личку.

А на счет того, как 1С узнает какой формат — так ей и не надо знать, ей достаточно получить URI на файл, что бы его забрать и загрузить в себя. Т.е. вопрос не в распознавании файлов, а вопрос в оповещении 1С о чем либо из других приложений.

Пример с файлом я привел, т.е. пришла накладная, я ее хочу привязать в 1С, я конечно могу ее сохранить, потом зайти в 1с, выбрать файл (причем очень аккуратно, так как 1С не умеет работать с контентом, надо именно полный путь) или написать свой файловый менеджер, и только потом выбрать файл и загрузить. Но этого можно избежать, т.е. пользователю достаточно будет отправить файл в 1С, и 1С откроется, появится окно, где 1С спросит — что это? РКО, ПКО, заявка и т.д., я нажимаю на что-то — и сразу создается документ в 1С с вложенными файлами.
По первой части — написал в личку.

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

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

Почему — писал выше. Иначе это выглядит так — мне пришло письмо, я захожу в 1С, опять получаю список писем там, получаю нужное письмо и делаю что-то с вложением.
Кроме этого — клиенты не особо любят при установке лицезреть целый список прав, которые требует приложение, и в частности — иногда не понимают, зачем 1С доступ ко всем аккаунтам устройства. Либо наоборот — зачем вводить авторизационные данные своего основного ящика — в 1С?
У меня был один вариант и я его привел :) И если я прав мы говорим об одном и том же — мой вопрос с форматами загружаемого файла остается в силе.
А про вложения — это был комментарий к тому, что в платформе сейчас, как кажется, есть нужные средства для работы с вложениями почты.
Если почта получается в другом клиенте, то как интерфейсно должно выглядеть действие по импорту из почты? Сейчас посмотрел GMail-клиента — там просто нет стандартного интерфейса расшаривания письма. Говоря о тех объектах, для которых доступен стандартный интерфейс «Поделиться» — да, понятно, как сделать. А с почтой как?
Вот про «Поделиться» я и говорил, извиняюсь что ввел в заблуждение словом «отправить». Ясное дело — просто так файл с почты отправить в другое приложение — звучит как-то более, чем никак.

С другой стороны, сказать «поделиться» с приложением, тоже не совсем.
Но главное, что мы поняли друг друга :)
Да кажется, что нет :)
Давайте еще раз:
1. (простое) делиться в 1С картинками и прочими постами из Pocket`а (например) — более-менее понятно как предлагается. Стандартная кнопка и там есть Предприятие. Тут вроде все понятно.
2. (сложное) есть почта, в которую пришло письмо. В письме вложение и надо это затащить в мобильное приложение. И вот тут — непонятно: сходу не видно, как поделиться письмом в Предприятие (тот же gmail-клиент это не умеет). Сходу не понятно, как этот пресловутый pdf уверенно преобразовать в документ платформы и т.д. Но если использовать для рабочего ящика мобильное приложение в качестве почтового клиента, то вопрос о том, как доставить письмо в приложение кажется вполне решенным. А вопрос «как pdf конвертировать в документ» — совсем за рамками мобильного приложения лежит.
Ок. Последний каммент :)
А то все обретает весьма запутанный вид.
Забудьте про почту вообще, и про все что с ней связано.

Представим себе, что у меня есть некий файл на телефоне, и вообще не важно то, как он туда попал. Просто файл, совсем не важно какой он.
Моя задача — поместить файл в мобильную 1С.
Тут есть два варианта решения:
1. Я его каким-то образом забираю из 1С; Например пишу в 1С uri к этому файлу, и она забирает его с телефона, и сохраняет у себя в базе. Что уже можно сделать, хотя и костыльно.
2. Я его каким-то образом «отправляю» в 1С. Например, как я прикрепляю этот файл к письму, или отправляю в дропбокс, гуглдрайв и т.д.

На языке программиста:
Мне надо что бы 1С умела отвечать на конкретные интенты, и могла как-то на них реагировать. Пусть у нее не будет возможности создавать фильтры намерений, а будет предопределенный список, например SEND.
Ну с этого надо было начинать :) А то — почта-почта :)
Да, это понятно, спасибо.
Осталось только понять — для чего (с точки зрения бизнес-приложения) такое надо (помещение любого файла в приложение на 1С)?
Какая типичная задача не решается без такой фичи?
Моя задача — поместить файл в мобильную 1С.
Тут есть два варианта решения:
1. Я его каким-то образом забираю из 1С; Например пишу в 1С uri к этому файлу, и она забирает его с телефона, и сохраняет у себя в базе. Что уже можно сделать, хотя и костыльно.
2. Я его каким-то образом «отправляю» в 1С. Например, как я прикрепляю этот файл к письму, или отправляю в дропбокс, гуглдрайв и т.д.
Это техническая проблема. А какую бизнес-проблему вы решаете такой конструкцией — непонятно.
В варианте со сканером вы это изложили отлично: инвентаризация, с которой не справляется текущая реализация сканера ШК (по удобству и скорости).
Хочется немного про внутреннюю архитектуру веб-клиента. Как организационно добиваетесь идентичности поведения с тонким клиентом?
Интересная статья. Хотелось бы узнать, а для чего в платформе 1С 8.3 для Linux в зависимостях платформы и тонкого клиента находится сервер, и планируется ли их разделить?
Коллеги подсказывают: дело в том, что толстый клиент и сервер разделяют большое количество компонент, поэтому данную зависимость можно трактовать как «зависимость толстого клиента от компонент, содержащихся в пакете сервера». Разделить их, конечно, планируется, но существенной разницы в наборе устанавливаемых компонент все равно не будет.
А тонкий клиент, наоборот, не зависит ни от одного пакета платформы и является самодостаточным пакетом.
Интересно узнать про вашу GUI-библиотеку (wbase).
Хорошее начало, надеюсь на продолжение. Огромный продукт, миллионы технических решений. Уверен вам есть о чем рассказать.
«интересен процесс выбора фич для новых релизов, разработки и тестирования?» — глосую за этот пункт!

И ещё интересно, используете ли вы какие-то статические анализаторы кода (типа PVS Studio) или «санитайзеры» (о которых часто слышу упоминания в новостях про исправленные баги в Chrome)?

Смотрели ли вы на такие свежие и модные технологии, как Rust и Go? (безопасная работа с памятью и хорошая поддержка параллелизма)

bsl — движок исполнения встроенного языка — медленно, очень медленно товарищи! Стоит ли вопрос производительности в планах и с каким приоритетом? Как насчёт многопоточности?
движок исполнения встроенного языка — медленно, очень медленно товарищи!

Из общего интереса — есть прецеденты, когда конфигурацию тормозит именно встроенный язык, а не работа с базой данных?
Если «да» — что это за прецеденты?
Есть прецеденты. Сериализация JSON скриптом 1С. На данных из примерно 5 тысяч записей таблицы значений перевод в XML уменьшил время обработки со 120 секунд (2 минуты) до 4 секунд.
А зачем писать JSON-сериализацию с помощью встроенного языка?
У вас в 1С принят стандартный дибильный подход к своим пользователям. Будь-то конечный пользователь или разработчик. Сначала пользователь сообщает вам о проблеме. Вы просите привести примеры. Когда приводят примеры, вы спрашиваете, а зачем вам это надо. После следует обвинение в том, что пользователь не так использует платформу или не умеет пользоваться. Все дураки вокруг, кроме вас. Такой подход полностью неприемлем. Это больше связано не с тем, что вы монополисты, и вам плевать на всех вокруг с высокой колокольни (но и монополисты могут вымереть в один прекрасный момент, как мамонты). Это связано больше с тем, что вы выходите на международный уровень: проект 1c-dn.com. Там, чтобы конкурировать на новом и незнакомом вам рынке, нужно идти навстречу пользователям, важна каждая мелочь. На Западе, например, неприемлемым считается выпуск в релиз фактически бета-версий платформы, чтобы пользователи дотестили ее за вас на местах. Весь заявленный функционал должен стабильно работать.

Теперь конкретно про данную ситуацию. Вас 3 разработчика в комментариях критиковали за медленный скриптовый язык 1С. А он медленный и стал объективно медленней при переходе с 8.2 на 8.3: вот исследование habrahabr.ru/post/245687 Судя по вашей реакции, это в порядке вещей. Вы не согласились с проблемой и не обосновали издержки какой-то новой фичей (напрашивается только технологический журнал). Да, скорость обращений к БД и к серверу затратнее, но это не значит, что нет класса задач, для которых важна скорость скрипта 1С. Его скорость влияет даже на отзывчивость интерфейса. Вам в habrahabr.ru/company/1c/blog/269611/?reply_to=8642701#comment_8640547 привели еще один пример по вычислениями на стороне сервера.

Теперь про JSON. Сериализация JSON для чего нужна, вам нужно объяснять? Или последует вопрос, зачем сериализация JSON в учетной системе 1С, 1С не для этого? JSON на встроенном языке 1С появился примерно с 2012 года (http://infostart.ru/public/119601/). До выхода свежей версии 1С, где вы соизволили сделать реализацию JSON на уровне платформы. Но, то, что вы сделали свою убыстренную реализацию это еще не значит, что она будет сразу отлаженная и рабочая, что все, кто использовал старую платформу сразу пересядут на новую версию. Самое главное, что вы не закрыли весь класс проблем по скорости сериализаций всех возможных в мире форматов. Кстати, Вы в курсе, что даже JSON может быть несовместим между вендорами. Например, в Web JavaScript JSON допускает вольность с unknown (a=unknown без кавычек), а Microsoft WCF не понимает такой вольности. Вы по какому стандарту сериализацию делали? А какую нужно будет доделать самостоятельно опять же на вашем медленном скрипте?
У вас в 1С принят стандартный дибильный подход к своим пользователям.

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

А он медленный и стал объективно медленней при переходе с 8.2 на 8.3: вот исследование habrahabr.ru/post/245687

Я вот сейчас запустил тест из стати на 8.2.19 и 8.3.7. Последняя версия процентов на 10 быстрее

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

Вы по какому стандарту сериализацию делали?

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

А вообще, есть две спецификации:
www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf
www.ietf.org/rfc/rfc4627.txt

А про Web JavaScript JSON я не слышал.
Я вот сейчас запустил тест из стати на 8.2.19 и 8.3.7. Последняя версия процентов на 10 быстрее

Это на самом деле радует. У меня нет под рукой 8.3.7 и, насколько знаю, ее еще нет в широком пользовании.
Более того, если посмотреть Ваш же комментарий к исходной статье, то видно, что дело не в производительности встроенного языка, а в работе функции «СтрЗаменить». Все-таки медленная работа конкретной функции и медленная скорость работы языка это очень разные вещи.

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

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

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

А про Web JavaScript JSON я не слышал.

Часто десериализацию на стороне веб-клиента делают так:
        var c = eval('({x:5, y:undefined})');
        console.log(c.y);

конструкция y:undefined в этом контексте является валидной, но такая запись, насколько помню, не подходит под официальные стандарты.
Медленную скорость работы языка я продемонстрировал ссылкой на статью, где вычислялось, какой цикл быстрее. Я подробностей исследования не помню. Но если формально подходить, то вызов СтрЗаменить транслируется в свой особый ОП-код 100, т.е. является элементом встроенного языка. Получается, что медленно работает и весь код в целом, и СтрЗаменить в частности.


Нет, не транслируется. Это вызов библиотечной функции.

Часто десериализацию на стороне веб-клиента делают так:
var c = eval('({x:5, y:undefined})');
console.log(c.y);

конструкция y:undefined в этом контексте является валидной, но такая запись, насколько помню, не подходит под официальные стандарты


А это просто неправильно и опасно. Правильно использовать json.parse()

JSON это все-таки не JavaScript
Ваши ответы просто поражают компетентностью. А потом вы обижаетесь, когда применяются честные и правильные речевые обороты к вашей компании и поведению ваших работников.

Нет, не транслируется. Это вызов библиотечной функции.

Я утверждаю, что СтрЗаменить транслируется в отдельный ОП-код на основании того, что писал в свое время декомпилятор 1С. Вот несколько ОП-кодов, включая №100:
EndOfMinute = 98,
CurDate = 99,
<b>StrReplace = 100,</b>
LinesCount = 101,


А это просто неправильно и опасно. Правильно использовать json.parse()

Ваш веб-клиент 1С 8.3.5 буквально напичкан вызовами eval для json-парсинга. А веб-модуль расширения 1С позволяет себе JSON вида y:undefined. У вас еще и веб-клиент опасный? :) Да, возможно, это небезопасно, но в реальной жизни это применяется. Возможно, для лучшей совместимости со старыми браузерами. Реальная жизнь другая. Ваш новый гибкий встроенный JSON-парсер справится?
Я утверждаю, что СтрЗаменить транслируется в отдельный ОП-код на основании того, что писал в свое время декомпилятор 1С. Вот несколько ОП-кодов, включая №100:

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

Десериализация через eval — зло, даже если это используют «миллионы мух», в том числе и сама платформа 1С.
Я не в белом, не на коне и не мушкетер, но ответить все-таки попытаюсь :)
Ваши фантазии по поводу того, что и почему мы делаем оставлю без комментариев, т.к. нет предмета для комментария.
Теперь про конкретную ситуацию.
Когда нас критикуют за медленный язык, мы пытаемся понять — что пытается реализовать разработчик такого, что встроенный язык начинает влиять на реактивность системы, насколько часто возникает описываемая ситуация и сколько людей используют этот механизм. Если будут выявлены реальные сценарии, когда скорость интерпретатора является реальным тормозом — значит будем анализировать такие случаи и думать, как решить проблему. В общем случае — мы не считаем, что скорость встроенного языка является существенной проблемой в данный момент. Что, однако, не исключает того, что мы готовы рассматривать конкретные проблемы и их решать. Но вначале проблему надо понять и оценить ее влияние на конфигурации. Если проблему поднимают 3 человека (да и даже если 103), а пользуются платформой несколько сотен тысяч, то надо хорошо представлять себе, насколько эта проблема реальна. Если вы считаете, что рассказать, нам о том, как мы не умеем программировать важнее, чем привести реальный сценарий — ок, позиция понятна :)
В примере с серверными вычислениями есть только один момент, который выглядит не очевидным: лично я совсем не уверен, что быстрый скрипт был-бы быстрее того же расчета на сервере, через временные таблицы. В данном случае мои сомнения и предположения коллеги (@svcoder) примерно равновероятны. Возможно, разработчики ERP дополнительно озадачивались данным вопросом и приняли текущее решение не просто так. Но, однако, пример как таковой кажется вполне логичным и понятным.
Теперь про JSON. Скажите, из какого вашего сообщений следует, что вы написали JSON-сериализацию тогда, когда ее не было в платформе? Я этого не увидел. Поэтому и уточнил — зачем ее писать самостоятельно? Вы меня стали подозревать в каких-то страшных грехах:) Также оставим за скобками то, что ваша реализация отлажена по умолчанию, а наша — глючна по умолчанию :)
Самое главное, что мы стараемся закрывать достаточно популярные и критичные моменты, причем для оценки популярности и критичности стараемся использовать не только свое мнение, но и мнение пользователей и партнеров. А для этого пытаемся узнавать — какую бизнес-задачу мешает реализовать та или иная возможность (или ее отсутствие) в платформе.
Проблемы производительности мы стараемся решать. Прилагаемые усилия видны и в списке изменений и на выступлениях на семинарах. Понятно, что это происходит в свежих версиях платформы.
ЗЫ: И все-таки предлагаю быть более конструктивным. Если стоит цель доказать нам, что мы не умеем писать экономический софт — наверное мы сразу согласимся :) Ну может быть попросим научить нас его писать качественно (даже вакансии открыты http://1c.ru/rus/firm1c/vacan/, особенно вот http://1c.ru/rus/firm1c/vacan/vacancy.jsp?id=201).
Ваши фантазии по поводу того, что и почему мы делаем оставлю без комментариев, т.к. нет предмета для комментария.

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

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

Критику медленного языка 1С можно разделить на 2 части: он вообще медленный, и он стал медленнее при переходе с 8.2 на 8.3 ( habrahabr.ru/post/245687 ). Меня сильно задевает именно второй момент. Качество фичи можно измерить объективными показателями. Качество языка 1С можно измерить поддерживаемыми конструкциями и скоростью выполнения. При неизменных конструкциях (развития языка нет) вы его замедлили. Значит качество этой фичи ухудшилось, соответственно общее качество продукта тоже. Это неуважение ко мне и ко всем пользователям. А вы проблемы не видите. Соответственно ничто не может вас остановить от дальнейшего ухудшения скорости в будущих версиях.

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

Теперь представьте, что вы замедлили работу языка 1С на 1 секунду в день у каждого пользователя. У всех своих многотысячных пользователей вы замедлили работу примерно на 55 часов (200000 * 1 / 3600). Цена вашего замедления очень высока. Вам не стыдно? :)

Если вы считаете, что рассказать, нам о том, как мы не умеем программировать важнее, чем привести реальный сценарий — ок, позиция понятна :)

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

Теперь про JSON. Скажите, из какого вашего сообщений следует, что вы написали JSON-сериализацию тогда, когда ее не было в платформе? Я этого не увидел. Поэтому и уточнил — зачем ее писать самостоятельно? Вы меня стали подозревать в каких-то страшных грехах:) Также оставим за скобками то, что ваша реализация отлажена по умолчанию, а наша — глючна по умолчанию :)

У вашей компании есть статистика по использованию новой 8.3.6, где есть JSON, по сравнению с более старыми версиями? Именно с такой вероятностью люди будут использовать новую фичу JSON. Кстати, опыт работы с вашим продуктом подсказывает, что свежайшая версия 1С богата ошибками и ее лучше использовать на реальных данных через год-два, когда вы исправите большинство ошибок.

ЗЫ: И все-таки предлагаю быть более конструктивным. Если стоит цель доказать нам, что мы не умеем писать экономический софт — наверное мы сразу согласимся :)

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

Ну может быть попросим научить нас его писать качественно (даже вакансии открыты 1c.ru/rus/firm1c/vacan, особенно вот 1c.ru/rus/firm1c/vacan/vacancy.jsp?id=201).

Вероятнее всего на Хабре вы найдете того, кого ищете. Здесь много хороших специалистов. То, что вы появились на Хабре — на независимом от вас ресурсе — это хороший знак. Это говорит о вашем стремлении к открытости и диалогу.
Критику медленного языка 1С можно разделить на 2 части: он вообще медленный, и он стал медленнее при переходе с 8.2 на 8.3
По первой части: критика имела бы смысл, присутствуй на рынке альтернативные платформы с аналогичными бизнес-объектами. SAP и MS Dynamics критикуют за низкую производительность не меньше.
По второй части: проблема, скорее всего, не в платформе, а в ошибке конкретного прикладного решения. С ситуациями, когда именно платформа не позволяла бы добиться приемлемой производительности, пока не сталкивался. Иногда, для решения этих проблем, приходится пересмотреть алгоритмы, структуру данных, бизнес-процессы или саму постановку задачи, но не надо ожидать от платформы чудес. Если писать на 1С неоптимальный код, выполняться он будет так же — не оптимально.
Вы статью смотрели: habrahabr.ru/post/245687?
Где там неоптимальный алгоритм в пустом цикле? Сделали замеры элементарных конструкций на разных версиях 1С.
Пустые циклы никак не характеризуют производительность платформы на тех задачах, для которых она предназначена. Важно другое: для типовых задач производительности хватает, а если возникают задачи специфические, платформа не мешает решить их внешними инструментами. Ваша статья про ускорение операций в 100 раз прямым обращением к БД тому подтверждение. В половине моих 1С-ных проектов используется генетическая оптимизация раскроя. Миллиарды генов рождаются и умирают за миллионы циклов эволюции. Естественно, генетика реализована снаружи на языке низкого уровня, но подготовка и обработка данных происходит в 1С. Никто не критикует PGAPack за то, что в его объектной модели отсутствуют документы и регистры. В 1С бизнес-объекты есть, а быстрых циклов нет. Это — нормально.
А разве общая производительность не складывается из производительности всех элементов, участвующих в коде: циклы, условия, вызовы? В статье на Хабре исследовались только циклы (это не значит, что скорость на других элементах не просела). Исследование показало, что скорость при переходе на 8.3 упала значительно. Все эти разговоры про назначение 1С, что она не предназначена для чего-то остается лирикой. Потому что факт простой: раньше работало быстро, в новой версии — значительно медленней. Качество упало. Представители 1С вразумительного ответа дать не могут. Более того, они считают падение производительностью в порядке вещей. Что не гарантирует от падения в следующих версиях тоже.

Понятно, что доля замедлений при обращениях к серверу и к БД выше, но элементарные операции очень сильно влияют на отзывчивость интерефейса. Отзывчивость заметна особенно, когда вы работаете на формах чистого C++ по сравнению с формами 1С, где навешаны события на кнопки.
О каких «модных» технологиях может идти речь если в статье явно описано, что они планируют только отказываться от STLport? Уже даже Android от него отказался!

В таких вещах всё планируется годами — уж очень высока цена неправильно сделанного выбора… а rust только-только вышел…
Интересно было бы узнать о реализации встроенного языка. Что он из себя представляет в архитектурном плане, что-то похожее на JavaVM или что-то ещё? То есть язык компилируется в байт-код своего формата или там другой механизм? По какому принципу добавляются новые конструкции и происходит разделение на то, что помещать на уровень платформы (что на клиент, что на сервер, что и и туда, и туда), а что вообще переносить на уровень БСП?
Там стековая машина с собственным байт-кодом
(что на клиент, что на сервер, что и и туда, и туда)

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

Скажите, пожалуйста, что именно не даёт Вам возможности собрать Win x64 «толстого» клиента для 8.3. Большое количество конфигураций просто нереально перенести на управляемые формы, а многие, в том числе типовые, отчёты на Win x86 просто не влезают по памяти!
Когда ждать прогресса в этом направлении?

Второй вопрос: 1С уже потихоньку появляется в Azure, а вот нормальную отказоустойчивость из-за «особенностей подключения» так и не получается реализовать. Планирется дли наконец использовать Native MS SQL client?
Спасибо.
отчёты на Win x86 просто не влезают по памяти

Простите, а что за отчет такой, который не влезает по памяти? Его человек потом анализирует?
не знаю какие отчеты имел ввиду DikSoft, но по своему опыту скажу, что не все отчеты формируются для того, чтобы «человек его потом анализировал», есть отчеты, которые нужно «распечатать, сшить, положить в шкаф и хранить 5 лет», и иногда на такой отчет не хватает пачки бумаги, ситуации разные бывают и не все зависит от наших с вами взглядов, есть начальство, которое говорит что нужно, есть политика ведения учета, архивов (в том числе и на бумаге)
Согласен, но тогда это серверный код, а сервер есть в x64. Впрочем, если я ничего не напутал, то DikSoft уже ответил мне в Google+ и привел пример, когда это нужно в клиенте.
в моем случае это было еще в файл-серверной 7.7, которая, кстати, до сих под жива
Размер данных, которые используются может быть существенно больше, чем то, что этот отчёт выводит. Неожиданно, да?

Пример из типовых: отчёт по НДС. Клиент выжрал 2 Гб и выпал по ошибке. Бухгалтера «шаманят» убирая и консолидируя что-то вручную, чтобы влезло. Это ненормально.

Про «перепишите и оптимизируйте» писать не нужно. В курсе. Вопрос в ресурсах. В 8.2 работало. В 8.3 не работает. В то же время не переходить нельзя, т.к. часть регламентированной отчётности может работать _только_ под 8.3.6.

Вопрос: Что мешает 1С собрать Win x64 толстого клиента?
Решение на базе ERP 2.0. Конфигуратор при сравнении\объединение в процессе обновления на ERP 2.1 постоянно падал с ошибкой нехватки памяти (то при просто разворачивании какой-то ветки метаданных в окне сравнения\объединения, то при вызове сравнения структуры двух модулей). Попытались обновиться в Linux x64, но там конфигуратор падал на гораздо более банальных вещах. В итоге удалось обновиться в Windows, но с настройками установленными автоматически, без внесения каких-либо правок при сравнении\объединении, а затем переносить все изменения вручную. Операция на которую рассчитывали потратить день растянулась на неспешную неделю :) Нам очень нужен Win x64 конфигуратор.
Ну «Конфигураторский» merge — это отдельный адский ад, плачъ и стенания ((( Надеемся только на выход Eclipse-версии и адекватную поддержку git. То, что предлагается для слияния кода сейчас (в 2015 году и на масштабах ERP) — это даже не смешно.
Планирется дли наконец использовать Native MS SQL client?

Версия 8.2.17:
Для работы с Microsoft SQL Server возможно использование Native Client. При использовании Native Client возможно использование протокола SHARED MEMORY, если оба сервера находятся на одном компьютере.
Пруф: downloads.v8.1c.ru/content//Platform/8_3_7_1633/1cv8upd.htm#79789069-b207-11e1-b815-e61f135f174b
Мы не используем стандартные контролы Windows, наши элементы управления реализованы напрямую на Windows API. Для Linux-версии сделана прослойка, работающая через библиотеку wxWidgets.
Библиотека элементов управления не зависит от других частей «1С: Предприятия» и используется нами еще в нескольких небольших внутренних утилитах.
Вот за это вам гореть в аду. Остальное ok.
Простите, а почему эта особенность вызвала у вас такую нервную реакцию?
Как пользователь 1с разделяю мнение mvs. Много боли и страданий приходится претерпеть в попытках кастомизировать интерфейс. Мне вообще непонятно такое маниакальное стремление использоватьь везде свои контролы. Уж лучше сосредоточились бы на бэкэнде, к фронтэнд отдали юзерам. Битрикс — прекрасный пример, что эта схема работает.
Это другое. Степень кастомизации интерфейса мало зависит от технологии контролов. Я не уверен, что Вам бы помогло, если бы использовались стандартные Windows-контролы, но идеология интерфейса оставалась той же.

А какой именно кастомизации Вам не хватает?
Мне не хватает:
— Сортировки окон в толстом клиенте как в браузере (зачем то есть только по алфавиту и все, и то, только через меню).
— Чекбокса просмотра по умолчанию при добавлении изображений в хранилище дополнительной информации (он есть, но по умолчанию поставить нельзя – лишний клик).
— Хотелось бы переделать направленный поиск (вообще, поиск – слабое место в 1с, к примеру: ставим пробел после значения в Ведомости по товарам на складах – ничего не найдем, а в номенклатуре при тех же раскладах ищет).
— Какая-то странная реализация работы с HTML в почтовом клиенте.
— Всплывающие подсказки выводятся только в тех ячейках, в которые не влез текст целиком. Изменить это нельзя. Вывести свои подсказки тоже нельзя. Изменить цвет подсказок — нельзя.
— Указывать контактными лицами существующих контрагентов.
— При работе с табличным документом, при фокусе в ячейке, выделять и строку и столбец.
— В некоторых таблицах это нужно при наведении мышки.
Ну еще много чего, что бегло вспомнилось.
Вы очень сильно смешиваете платформу и конфигурации.

К платформе относится, пожалуй, только

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


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

Для чего я все это написал? Чтобы показать, что вы никогда не решите все за всех. Потребности разные. Отдайте фронтэнд.
Направленный поиск — только вверх или только вниз ищет по столбцу.

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

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

Про всплывающие подсказки вообще не понял — зачем и к чему.

Но есть проблемы и приходится вникать, ибо я не мог поверить сначала кодерам, кому ставил ТЗ

А на основании чего поверили? Если не секрет. Т.е. вы нашли реально признанных в наших кругах гуру 1С, съездили на конференцию, выцепили там элиту, спросили у них, и они сказали что так нельзя? И вообще никак по другому тоже нельзя?

Я к чему — я еще за свою практику ни разу не встречал задачи, которую я бы не смог решить средствами 1С, или неким самописным расширением для нее.
Ну если вы не можете придумать задачи, где это требуется, тогда конечно да — это никому не нужно.
Не обрезайте смысл.
Если вы не можете поставить задачу так, что бы ее можно было решить, то тогда ее не имеет смысла решать, возможно именно по этому ваши программисты и говорят, что что-то там сделать нельзя. Задумайтесь над этим, а то напоминает тот ролик, где просили нарисовать 7 красных линий перпендиклярно друг другу, 3 синим цветом и 2 прозрачные.

Это конечно не оправдывает платформу, но и те проблемы которые вы описали — являются больше надуманными, чем реальными. Хотя в ней и более реальных проблем хватает :)
И только вы один Дартаньян. Ок.
Почти. Я не один, но нас мало, увы.
Ну, если я смешал платформу и конфигурацию, то мне простительно, т.к. я рассуждаю с позиции пользователя. Черт, да я вообще не должен знать таких слов.

Вообще, изначально речь шла о кастомизации интерфейса, а это тема программиста.

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

Для чего я все это написал? Чтобы показать, что вы никогда не решите все за всех. Потребности разные. Отдайте фронтэнд.


А, собственно, никто не мешает. Вот, например, что партнеры делают:
www.oknosoft.ru/metadata
«Вообще, изначально речь шла о кастомизации интерфейса, а это тема программиста».

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


Никто не заставляет именно программиста разрабатывать интерфейс конкретного прикладного решения.
Василий, интересно, кстати, услышать Ваше мнение про metadata.js в вашей ссылке. Оно взлетит?
Боюсь, у меня нет мнения. Чтобы оценить, нужно попробовать поработать более 10 минут.
мнение про metadata.js в вашей ссылке. Оно взлетит?
Взлететь может в двух случаях:
  • 1C и партнеры захотят освоить новый для них рынок веб-приложений
  • Веб-разработчики заинтересуются сервером 1С для своих проектов
Вероятность и первого и второго больше нуля. В прикладных решениях 1С накоплен огромный методический опыт и эффективная бизнес-логика, которой, imho, не повредит лёгкий javascript интерфейс, да еще и с поддержкой автономной работы.
У меня точно такая же реакция на тех, кто норовит стилизовать input'ы и другие контролы в вебе, Android-приложениям делает iOS-образный внешний вид, а Windows-приложения (к примеру) темезирует так, что их не узнать.
Если что-то выглядит как утка и крякает как утка, значит это утка. Но если утка выглядит как лось, а крякает соловьём, это уже нифига не утка.

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

В конце-концов, если хочется выпендриться с оформлением, то давно есть интерфейс Ribbon (начинания с Microsoft Office 2010 и Windows 8). Более-менее удобен, более-менее стандартен как для ОС, так и для многих приложений, пользователи так или иначе привыкают к нему, поскольку он используется во всей ОС в целом, а не в отдельном приложении.
А вы работали с 1С: Предприятие?

Если используется другая реализация контролов, то это не значит, что нарушается логика стандартная логика приложения Windows или даже логика внешнего вида.
Основная цель интерфейса Предприятия — обеспечение единого пользовательского опыта на всех платформах, где пользователь может использовать прикладное решение, разработанное на платформе. Другими словами, человек, который привык/научился работать с какой-то конфигурацией, работающей под Виндой, то этот опыт (практически без изменений) пригодится ему в Linux и в веб-клиенте и, отчасти, на мобильных устройствах (хотя тут, очевидно, прямого переноса опыта не может быть, что называется by design).
Можно обсуждать, насколько хорош такой подход, но сейчас он такой. Собственно излишняя кастомизация интерфейса такому подходу изрядно мешает. Излишняя кастомизация — это значит, что пользователю каждый раз надо вникать и привыкать.
Глобальная задача при разработке платформы — обеспечение единого поведения интерфейса на всех поддерживаемых платформах. Ну и плюс узнаваемость этого интерфейса.
Эту мантру я слышал. По такой логике все сайты должны быть одинаковыми.
Думаю, тут очевидно, что такой подход давно устарел.
Это не мантра, а текущий подход.
По такой логике все сайты должны быть одинаковыми.

По какой логике? Я не слышал, чтобы кто-то пытался пропагандировать такой подход. Однако тот же Google пытается выстраивать интерфейсы своих приложений так, чтобы пользовательских опыт сохранялся при переходе между Андроидом и вебом. Наверное они не зря переделывают свои веб-приложения в Material Design.
Думаю, тут очевидно, что такой подход давно устарел.

Можете привести причины?
Извините, но нахрена вот это вот всё? ЦА 1С (и БП, и УТ, и Предприятия в целом) — бухгалтерия, руководители и менеджеры непонятного уровня. Выберите один из двух вариантов поведения указанной ЦА в работе:
  1. Утром работаю на Windows, вечером на Mac OS, иногда делаю красные галаза и включаю Linux. Мне жизненно нужна абсолютно одинаковая 1С для каждой ОС, пусть даже в ущерб логике работы самой ОС.
  2. Работаю на Windows XP/7/8 с 1С, Excel, Word, клиент-банком в офисе; вечером или в выходные по срочным вопросам использую бук с Windows 10 и таким же набором ПО. Мне не важна консистентность интерфейса 1С для разных платформ, но я хочу удобную работу в ней наравне и с другими привычными программами.

Очевидный для меня вариант выделен.
Извините, но нахрена вот это вот всё?

Возможно потому, что есть еще другие варианты, кроме перечисленных. Например, на работе Windows, дома (иногда) Mac на веб-клиенте. Иногда какое-то мобильное устройство. Или, например, в офисе Windows, вне офиса iPad/планшет на Андроиде через мобильное приложение или веб-клиент.
Возможно потому, что наши данные о применении системы показывают, что наш подход оправдан.
Возможно потому, что жизнь на монохромная, и вариантов использования чуть больше, чем 2.
Какие темы были бы интересны Вам в следующих статьях?

Все три!
Пример со своего предприятия. Раз в неделю приходится перезагружать серверные процессы 1С (ест-но версия x64) — банальная утечка памяти за неделю кушает 100Гб оперативы, когда выедает полностью — процесс перестаёт отвечать. Размер баз MsSQL — 350Гб, крутятся отдельно.
Очень интересно услышать, как происходит разработка и тестирование кода, и как он попадает в новые релизы.
А интервал перезапуска рабочих процессов в свойствах кластера почему не выставите?
Подозреваю, что утечка памяти в проектах на си — один из самых больных вопросов. А про процесс тестирования и покрытия кода тестами тоже услышать хотелось бы.
Утечки памяти на сервере может вызывать и прикладной код на встроенном языке. Управление памятью происходит через подсчет ссылок, циклические ссылки между объектами могут приводить к появлению «потерянных объектов» на которые нет ссылок.
Это можно отследить по технологическому журналу платформы.
Интересно узнать про Native API. Понятно, что для Linux нужен был принципиально другой подход. Но он стал ограниченнее COM API: поддерживает только простейшие типы, а поддержку IDispatch не сделали. Native API в Windows не интегрируется с .Net framework, как раньше COM API. /CLR-реализация интеграции через С++ приводит к Loader Lock.
PeterG, коллеги!

Объясните пожалуйста зачем вы всё это делаете?

Вот это всё: «Движок исполнения встроенного языка», «Собственная реализация аллокатора памяти», «Простая файл-серверная машина баз данных, основанная на ISAM, включающая также простой SQL-процессор», для чего? Когда есть уже давно написанные и отполированные библиотеки и быстрые RDBMS SQL и noSQL.

Почему вы не придерживаетесь принятой во всем Мире терминологии, а вместо этого придумываете все эти свои «Платформа», «Конфигурация», «Тонкий клиент», «Толстый клиент»? Которые понять _что_это_такое_ ВООБЩЕ не представляется возможным, потому что армия ваших «программистов» не в состоянии даже объяснить это, т.к. они сами не владеют методологическими знаниями, а вместо этого располагают фактологической информацией и научились «тыкать куда надо, чтобы оно заработало»?

Как так вышло, что аккаунты на users.v8.1c.ru и its.1c.ru совершенно разные и не зависят друг от друга, и это при том, что для установки и работы с вашими продуктами требуется регистрация и там и там? У вас кто-то это вообще продумывает? Посмотрите на Apple ID или Microsoft Live ID.

Зачем писать бухгалтерскую программу на C++?

Почему вы не делаете свои приложения на Ruby, Python или Java, по всем понятной архитектуре клиент-сервер? И ведь можно было бы сделать backend и предоставить к нему доступ по REST API, написать свои клиентские приложения, которые общались бы с этим API, выпустить SDK под разные платформы, начиная от web-браузера и заканчивая iOS. Кроме того, можно было бы дать доступ к этому API любому стороннему разработчику, который, не сильно мучаясь и напрягаясь, мог бы интегрировать ваше «1С: Предприятие» в свою существующую инфраструктуру или написать собственный модуль, который делает что-то очень полезное и облегчит жизнь многим предприятиям.

Почему у вас все так сложно, медленно и невозможно работает?!

Потратив 2 недели на поиск специалиста, способного установить «1С: Предприятие» на Linux, нам в итоге пришлось справляться самим. В конечном счете качество работы системы оказалось совершенно неприемлемым: всё мега тормозит, «web-клиент» съедает 100% CPU и вешает браузер, потому-что он что-то там делает. КАК ЭТО ВОЗМОЖНО? Кто все это проектировал и писал?

К слову сказать, ни один из 3-4 диллеров, к которым мы обращались за тех.помощью по установке системы на Linux, не знает как это сделать. Все что мы слышали в трубке, это какое-то бормотание про «Платформа», «Конфигурация», «Тонкий клиент» в рандомном порядке. Люди на том конце провода ВООБЩЕ не имеют представления, как работает и устроен продукт, которым они торгуют. Никто даже внятно не смог объяснить, что такое ИТС и зачем оно нужно.

Если так вышло, что вы постоянно дописываете код вокруг написанной когда-то в конце 90-х / начале 00-вых программы, то неужели это не очевидно, что следует немедленно все остановить, перепроектировать на современный лад (микросервисы и пр.) и переписать все заново с нуля?

Ведь если этого не сделаете ВЫ, то найдется кто-то другой.

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

На дворе конец 2015-го года! Так обеспечьте же наконец приемлемое качество своего продукта.

Буду рад конструктивным ответам на критику.

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

Если так вышло, что вы постоянно дописываете код вокруг написанной когда-то в конце 90-х / начале 00-вых программы, то неужели это не очевидно, что следует немедленно все остановить, перепроектировать на современный лад (микросервисы и пр.) и переписать все заново с нуля?
Человек, которому это «очевидно» должен быть уволен сразу и немедленно. Про это писалось уже 1000 раз.

Ведь если этого не сделаете ВЫ, то найдется кто-то другой.
Несомненно. Но продукцию этого вот «другого» не сможет поддерживать армада людей, которые «не владеют методологическими знаниями, а вместо этого располагают фактологической информацией и научились «тыкать куда надо, чтобы оно заработало»!» И всё: это значит, что он проиграет. Ведь именно они — это и есть вся история! Вокруг них всё вертится! А если сделать так, как вы говорите, то они «выпадут из игры» — что и будет концом 1C.

Точно также как отказ от Win32 и переход на .NET стал «началом конца Windows» (хотя ещё лет 10 это будет очевидно не всем) отказ от C++ и переписывание всего этого хозяйства «на Ruby, Python или Java» будет концом 1C. Единственный вариант — это всё делать аккуратно и не спеша. Конфигуратор нового поколения на Java, к примеру, появился. Постепенно люди к нему привыкнут — и можно будет что-то ещё изменить.

Вот и вся история, в сущности. Если смотреть на неё не глазами программиста, а глазами бизнесмена.
Как-то даже сложно отвечать :)
Давайте вспомним, когда вышла первая версия текущей, 8-й версии, платформы? Это август 2002 года. Теперь вспомним о том, что все это надо было разработать и откинем от этого примерно еще несколько лет, пусть это будет 4 года. Итого: 1998 год. А теперь давайте вспомним, какие отлаженные, отполированные и т.д. настольные движки под Windows тогда были доступны, желательно во встраиваемом варианте? Чтобы можно было в режиме Next > Next > Next > Ok установить такой движок и начать работать, и который еще жив до сих пор…
Что касается терминов, так вроде ничего нового не изобретено: тонкий клиент, толстый клиент и т.д.
И все время давайте помнить о том, что разработка началась достаточно давно. Тогда с популярностью и отлаженностью всех современных технологий было немного по-другому. И развивая платформу (и прикладные решения на ее основе) обеспечение обратной совместимости — это огромная задача. Т.к. в разработку на платформе вложены огромные средства. И все заинтересованы в сохранении этих инвестиций. У клиентов работает огромное количество систем, с ними работает большое количество пользователей, ведется разработка и доработка новых систем и т.д.
А теперь представим, что фирма «1С» берет и говорит — всем стоять! Мы немедленно останавливаем всю доработку текущей платформы (да и поддержку тоже останавливаем, т.к. нам надо все быстро переписать) и начинаем делать другую платформу, которая будет современной и т.д. (прямо как в той шуточной истории про средства доступа к данным от Майкрософт :)). И есть у меня подозрение, граничащее с уверенностью, что к моменту окончания это новой разработки мы получим следующее:
1. разработка устареет, т.к. за время разработки сменятся технологии
2. текущие клиенты уйдут на другие платформы, т.к. людям надо иметь стабильную платформу для автоматизации и с предсказуемым и стабильным развитием и поведением
Ведь если этого не сделаете ВЫ, то найдется кто-то другой.

Значит у нас появится новый конкурент, к имеющимся сейчас SAP, Microsoft, Галактика и т.д.
К слову сказать, ни один из 3-4 диллеров, к которым мы обращались за тех.помощью по установке системы на Linux, не знает как это сделать.

Осталось только понять, как это замечание относится к собственно платформе :)
Может быть это связано с непопулярностью Линукса, как ОС для корпоративного применения? Может быть это связано с тем, что наши партнеры не видят [пока] перспектив для вложений в Линукс-компетенции своих сотрудников? Т.е. это проблема платформы или положения Линукса в корпоративной среде? Я сейчас не оцениваю качества Линукса, я просто задаю качественный вопрос.

Ошибки… это больной вопрос. В системе есть ошибки. Это математический факт. Протестировать всю возможную совокупность программно-аппаратных комплексов, использующихся у клиентов — невозможно по определению. Прикладывает-ли 1С усилия у повышению качества продукта? Да, прикладывает! Хватает этих усилий? Скорее всего не хватает, раз есть такой напористый негативный фидбэк.

И да, когда все резко переписывается, получается переход 7.x -> 8.x. Те, кто помнит то время, могут вспомнить, что тогда говорилось в адрес компании :)
И да, когда все резко переписывается, получается переход 7.x -> 8.x. Те, кто помнит то время, могут вспомнить, что тогда говорилось в адрес компании :)

К сожалению, не только «когда всё резко переписывается».
Толстого клиента Win x64 просто «потеряли по дороге» при «плавном переходе» с 8.2 на 8.3. Будет он вообще собран или нет?
Он не потерян, он не рождался.
Увы, в данный момент ничего внятного про клиент Win64 сказать не могу.
А есть, тот, кто может?
Так, чтобы без маркетинговых лозунгов «мы всё равно движемся в сторону классической трёхзвенки и тонких клиентов, поэтому решили, что вопрос через некоторое время станет неактуальным и не стали тратить ресурсы...» понятно описал, в каких именно библиотеках случился «затык». Явно же не от лени? Что случилось, что при всей расписанной выше универсальности и компоновке «вдруг» не получилось собрать на «родной» платформе достаточно востребованный компонент экосистемы?
Задача разработки клиента под Win64 нам известна; но на данный момент у нас есть более приоритетные с нашей точки зрения задачи.
Спасибо за ответ. Лихо, однако…
есть более приоритетные с нашей точки зрения задачи.

По Вашему обеспечить честно купившим не самую дешёвую x64 версию сохранение прежней функциональности это «ерунда и не стоит беспокойства, дело-то житейское» ???

И, кстати, раз уж та тема заявлена, как «что под капотом», может раскроете, в чем техническая сложность?

Помнится мне в блоге PVS-studio была отличная статья про то, почему нельзя просто так взять и пересобрать под x64.
Видимо, речь про эту статью: habrahabr.ru/company/pvs-studio/blog/264021?
Дык, там понятно, что «с нуля» переносили. А здесь же имеется:
Кодовая база сервера при этом общая на 99%, клиента — процентов на 95%

+ достаточно проработанная компонентная модель. (см. описание в статье).
В чем смысл кидания на произвол судьбы большого количества пользователей, погоня за новыми сегментами и клиентами? Или всё таки какие-то технологические сложности (устаревание MVS 2012, как средства для написания x64 приложений, с большими затратами на смену платформы разработки)?
Да, статья PVS эта. И еще ссылки в ней. Спасибо.
Кодовая база сервера при этом общая на 99%, клиента — процентов на 95%

Лично я эту фразу понял так: "кодовая база общая между windows и linux. Для сервера на 99%, для клиента на 95%"
Из этого тезиса нельзя сделать вывод, что 95% клиента уже совместимы с x64.
По Вашему обеспечить честно купившим не самую дешёвую x64 версию

Это х64 версия сервера, в прайс-листе так и написано.

сохранение прежней функциональности

Поясните пожалуйста, о чем речь? Про прежнюю функциональность.

может раскроете, в чем техническая сложность?

Сложность скорее не техническая; она — в объеме работ: введение нового компонента (х64 клиент) в структуру, встраивание в билд, создание тестов, документация, дистрибуция и т.д. и т.п. Все это — существенный объем работ. На который нужны ресурсы. А перед нами стоят и другие задачи, со своей стоимостью реализации и приоритетом. И вот на данный момент у других задач приоритет выше, чем у задачи создания клиента х64 под Windows.
Спасибо за понимание.
Это х64 версия сервера, в прайс-листе так и написано.
Согласен, версия сервера в первую очередь. Более дорогая. Под тяжёлые задачи. Так? А какой клиент был в 8.2 для больших и ресурсоёмких задач? — x64. В том числе и для огромных типовых отчётов.
Поясните пожалуйста, о чем речь? Про прежнюю функциональность.
Теперь плавно переходим к прежней функциональности. С утерей толстого клиента Win x64 для 8.3. потребитель потерял возможность без дополнительной (и очень дорогой!) доработки получить результат, который был доступен в 8.2. Тяжёлые отчёты перестали работать, упираясь во что? В то, что потребителя лишили толстого x64 клиента, но при этом заставили перейти на 8.3 той же типовой отчётностью! Крайне не люблю повторяться, но пришлось. Всё это уже написано выше.
… в объеме работ: введение нового компонента (х64 клиент) в структуру
Вы несколько противоречите написанному в этом же топике, говоря про написание с нуля «нового компонента». А как же модульность, 95% одинакового кода у клиентов «и вот это всё»?

Как-то ясности больше не стало. <грустный смайл> Как ИТ руководители должны аргументировать владельцам бизнеса покупку «допиливания» типовых отчётов у сторонних организаций, если они до этого писали, что покупается более дорогая 1С x64 именно по причине больших объёмов и тяжёлых задач?
Что можно сказать главбуху по поводу смысла продолжать покупать подписку ИТС, решающую важные текущие задачи, если задача не решается? Наличие типовых отчётов? Так их всё равно приходится фактически покупать у сторонней поддержки.

Вы сами-то признаёте, что проблема есть?
В 8.2 не было 64-битного клиента. Именно поэтому я ранее и написал, что он не утерян, он не рождался.
… т.е. причина бОльшей требовательности клиента к памяти не в смене среды выполнения (x64-->x86), а в том, что 8.3 существенно сложнее внутри и поэтому больше памяти требует под свои нужды?
Не очень понятно.
Я отвечал на ремарку:
А какой клиент был в 8.2 для больших и ресурсоёмких задач? — x64.

С утерей толстого клиента Win x64 для 8.3.

Одной из причин повышения потребностей в памяти служит существенное усложнение прикладных решений. Я думаю, что если написать на 8.х аналог конфигурации 7.7 (полностью эквивалентный, без расширения возможностей!) — получится маленькое и быстрое решение. Это ИМХО, возможно безосновательное :)
Ну вы жжоте, коллега! две трети того, что вы хотите в 1С давно есть. А если те к кому вы обращались не имеют прямых рук и не следят за развитием платформы, ну напишите здесь, кто это был и что именно не смог сделать. Думаю, если они будут продолжать в том же духе, то вылетят с рынка и все дела.
Расскажите лучше как у вас работает сборщик мусора, так как заметил что некоторые объекты невозможно удалить из памяти, а сборщик мусора вылезает когда памяти уже нет и надо что-то с этим сделать.

Например

ЭлементыФормы.ПолеКартинки.Картинка = Новый Картинка("ДИСК:\картинка.бмп");

То есть каждом присваивании память всегда занимается, но не очищается… печаль
Если у вас есть действующий договор ИТС — пришлите пожалуйста описание проблемы на v8@1c.ru.
Вы как используемую память отслеживаете? Каким софтом?
Хочется также узнать и о:
— работе 1С с СУБД Oracle. Из недавних примеров: типовой Документооборот КОРП 1.4 на Oracle жутко тормозит, а под MS SQL уже шевелится
— работе механизма RLS в Документообороте, точнее о скорости вычисления прав
1С-молодцы, конечно. Но при всех достоинствах системы есть несколько негативных, на мой взгляд, моментов:
1. Отсталость среды разработки по сравнению с Eclipse, VS
2. Неразвитость языка программирования 1С. В него долгое время не вводились новые конструкции.
3. Отсутствие модульного подхода, все решения получаются монолитными
4. Официальная политика 1С на закрытость системы. Например, запрет и гонения за прямой доступ к базе данных, за декомпиляторы 1С, внешние средства-дополнения к конфигуратору.
1С-молодцы, конечно

Спасибо! Мы стараемся)

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

Nobody's perfect

1. Отсталость среды разработки по сравнению с Eclipse, VS

Мы работаем в этом направлении, как вы наверное уже знаете.

2. Неразвитость языка программирования 1С. В него долгое время не вводились новые конструкции.

Чего именно не хватает в языке? Можно примеры?

3. Отсутствие модульного подхода, все решения получаются монолитными

Есть такое. У отсутствия модульного подхода есть как плюсы, так и минусы. Мы думаем в этом направлении, но планами пока делиться не готовы.

4. Официальная политика 1С на закрытость системы. Например, запрет и гонения за прямой доступ к базе данных, за декомпиляторы 1С, внешние средства-дополнения к конфигуратору.

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

Я знаю об этом. Ваша работа в этом направлении и открытый XML-формат конфигурации безусловно очень позитивные шаги. Они делают ненужными всякие парсеры cf-формата.
Чего именно не хватает в языке? Можно примеры?
Не хватает развития. Вы в статье перечислили много технологий и языков программирования. Как вы сами думаете язык 1С приближен по выразительности и возможностям к языкам C++, C#, Java или он остался на одном уровне с Ассемблером? Даже JavaScript, с оглядкой на который создавался 1С-язык, получил развитие в виде классов, пространств имен, анонимные callback-функции, а 1С- нет.
Это типичная политика большинства вендоров. Надеюсь, вы понимаете, чем она вызвана. В особенности вот это:
«гонения за прямой доступ к базе данных»

В том-то и дело, что перестал понимать. Эта политика устарела. С одной стороны она противоречит законодательству РФ, с другой стороны она противоречит вашей политике в отношении иностранных разработчиков:
1c-dn.com/library/data_structure_in_1c_enterprise_8
Судя по этой ссылке, у вас появилось неравное отношение к разработчикам СНГ и разработчикам из дальнего зарубежья. Для иностранцев — возьмите данные, они лежат там-то и там-то, для местных — запрещено лицензионным соглашением. Я так понимаю, ваша стандартная российская политика не работает в более развитых странах и чревата реакцией государств Евросоюза со штрафами. Хотелось бы видеть равное отношение.
С одной стороны она противоречит законодательству РФ

Можете привести ссылку на конкретный параграф закона?
, с другой стороны она противоречит вашей политике в отношении иностранных разработчиков:

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

Конечно:
ГК РФ Статья 1334. Исключительное право изготовителя базы данных
Изготовителю базы данных, создание которой (включая обработку или представление соответствующих материалов) требует существенных финансовых, материальных, организационных или иных затрат, принадлежит исключительное право извлекать из базы данных материалы и осуществлять их последующее использование в любой форме и любым способом...

ГК РФ Статья 1280. Свободное воспроизведение программ для ЭВМ и баз данных. Декомпилирование программ для ЭВМ
1. Лицо, правомерно владеющее экземпляром программы для ЭВМ или экземпляром базы данных (пользователь), вправе без разрешения автора или иного правообладателя и без выплаты дополнительного вознаграждения:
1) внести в программу для ЭВМ или базу данных изменения исключительно в целях их функционирования на технических средствах пользователя и осуществлять действия, необходимые для функционирования таких программы или базы данных в соответствии с их назначением, в том числе запись и хранение в памяти ЭВМ (одной ЭВМ или одного пользователя сети), а также осуществить исправление явных ошибок, если иное не предусмотрено договором с правообладателем;
А почему во второй цитате не выделено «если иное не предусмотрено договором с правообладателем»?
Потому что правообладателем базы данных в организации является сама организация в силу ее авторства, а не компания 1С.
Ничего не понял. Где нарушение? Какое нарушение?

Вы можете залезть в свою базу чем угодно и для чего угодно — и с этим правом разработчики 1C вполне согласны.

Пока это просто база и дальнейшее её использование совместно с 1C не предполагается. Тут, собственно, Статья 1280 вообще ни к селу ни к городу. База ваша — делайте что хотите. Но вот если предполагается использовать базу совместно с продуктом 1C — тут уже требуется лицензионное соглашение в котором чётко написано что руками лазить в базу — нельзя.
Ваше мнение тоже имеет право на существование. Но оно не убедительно. Простыми словами: база данных моя, что хочу с ней то и делаю. Хочу копирую, хочу удаляю, хочу пускаю кого-то в нее со стороны. Кстати, в одной базе данных у меня могут работать несколько приложений в т.ч. 1С. Никто не вправе со стороны говорить мне, что мне делать со своей собственностью. Все равно, что вы купили квартиру, а интернет-провайдер добавил пункт в договор, что в вашу квартиру вообще никакие провода кроме его идти не должны.

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

И если штатными средствами операция будет длиться 3 суток, то прямым доступом она завершится за 45 минут.
Это скорее повод обратиться к разработчику и попросить сделать нужный вам API, а не повод лезть «грязными ручками» в базу из которой потом финансовые документы порождаются.

Опять-таки: если после лазанья в базу вы больше оных финансовых документов порождать не будете, то и 1C от вас, наверняка, отвяжется тоже. А так — я прекрасно понимаю почему у них такая политика: если вы залезете в базу и чего-то там поменяете, то без подобного пункта в договоре за все ваши косяки могла бы отвачать 1C. А так всё просто: вы залезли в базу (нарушив тем самым лицензию), целостность её состояния более не гарантируются, так что никаких претензий к 1C больше быть не может.
Ну если вы подписали такой договор — то кто ж вам теперь судья? Эксклюзивные договоры — штука вполне логичная.

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

Вы до сих пор верите в отзывчивость 1С? У 1С очень циничный подход. Компания занимается только тем, чем выгодно. И разработчики здесь не при делах. Разработчики подчиняются руководству 1С. АПИ вы будете ждать до «ишачьей пасхи», а результат нужен завтра.
А так всё просто: вы залезли в базу (нарушив тем самым лицензию), целостность её состояния более не гарантируются, так что никаких претензий к 1C больше быть не может.

Нужно посмотреть документы. Уверен, что в них явно прописан отказ от претензий. Что-то в виде используете ПО 1С на свой страх и риск. 1С сама не гарантирует целостность данных. Убираешь режим совместимости — пропадают узлы обмена из списка. Ставишь разделение итогов на регистр бухгалтерии — пропадают субконто за все годы. В последнем случае как без прямого доступа восстанавливать базу данных?
1С же фактически монополист и подобные запреты дело антимонопольных органов.
Возможно. Но пока антимонопольные органы своего веского слова не сказали — вы ничего сделать не можете. Dura lex, sed lex.

Нужно посмотреть документы. Уверен, что в них явно прописан отказ от претензий. Что-то в виде используете ПО 1С на свой страх и риск.
Конечно прописано. Более того — как всем известно иначе и быть не может, если повесить на 1C не только права, но и обязанности — небо упадёт на землю и мы все будем покупать операционки по 10миллинов долларов за штуку. Вы этого хотели? Кушайте, пожалуйста, не обляпайтесь.

Вы до сих пор верите в отзывчивость 1С? У 1С очень циничный подход. Компания занимается только тем, чем выгодно. И разработчики здесь не при делах. Разработчики подчиняются руководству 1С. АПИ вы будете ждать до «ишачьей пасхи», а результат нужен завтра.
Я вас очень хорошо понимаю. Но, тем не менее, есть закон. Если он не даёт людям жизнь, то это повод его изменить и не повод на него наплевать, уж извините. Изменять его никто не хочет (смотри дискуссию по вышеприведённой ссылке), так что придётся жить с чем есть.
Смысла не вижу продолжать дискуссию. Вы начали себе противоречить.

Сначала вы утверждали, что 1С не сможет отвечать после прямого доступа в базу данных, но сейчас согласились, что 1С и так ни за что не отвечает. Так в чем принципиальная разница? Не отвечала 1С раньше и не отвечает она после.
В конце вообще вы сожалеете о каком-то законе, «не дающем людям жизнь». Но закон явно говорит о защите прав на прямой доступ к базе данных. Ссылки на конкретные статьи я привел в посте выше
habrahabr.ru/company/1c/blog/269611/?reply_to=8637909#comment_8634219
Статья стала ценной не только содержанием, но и комментариями, где можно для себя по ссылкам много нового и интересного найти.
Хотелось бы получить ответ на следующие вопросы.
1. С чем связан отказ от тонкой кастомизации работы с БД. Ваша цель понятна — одинаковая работа приложения на всех 4-х СУБД, включая файловую версию. Но моя многолетняя практика работы на крупных проектах показывает, что смена БД в течение эксплуатации не происходит никогда. Разумеется, что MS SQL Server развивается гораздо быстрее файловой ИБ, но ведь клиент покупает вместе с 1С лицензии на MS SQL Server вместе со всеми своими функциями, но пользоваться ими не может. Вот некоторое из того, чего реально не хватает:
1.1. Добавление нескольких индексов по произвольным полям
1.2. Получение номера строки выборки ROW_NUMBER в MS SQL Server
1.3. Коррелированные подзапросы

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

2. Добавление бинарной трансляции p-кода. Вас не расстаивает, что Java-Script на веб-клиенте выполняется в тысячи раз быстрее встроенного языка?

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

4. Судя по ERP 2 произошел крутой поворот в сторону выполнения всей логики на СУБД. На мой взгляд это шаг назад, так как алгоритмические языки всегда более понятные и удобные для поддержки/доработки чем скрипты на SQL. Так и до PL/SQL можно дойти

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

Вы же сами и ответили:
одинаковая работа приложения на всех 4-х СУБД, включая файловую версию

Если включать файловую версию — то на 5-ти СУБД.

2. Добавление бинарной трансляции p-кода. Вас не расстаивает, что Java-Script на веб-клиенте выполняется в тысячи раз быстрее встроенного языка?

Наверное, JavaScript при этом не делает все то же самое, что встроенный язык? Например, читает регистры из БД, делает отчеты и т.п.
Случаев, когда тормозит именно язык (а не доступ к БД например)- на деле не очень много. Выше уже обсуждали.

4. Судя по ERP 2 произошел крутой поворот в сторону выполнения всей логики на СУБД.

Коллега, можете пояснить примерами, что вы имеете в виду? Насколько знаю, хранимых процедур, специфичных для ERP, в конфигурации не появилось.
алгоритмические языки всегда более понятные и удобные для поддержки/доработки чем скрипты на SQL

Согласен 100%.

5. Когда наконец произойдет отказ от хранения текстов требующих перевода в отдельной части дерева конфигурации

Согласен, сейчас сделано не вполне удобно.
Опция «Редактирование текстов интерфейса» несколько облегчает работу, но целиком проблему не решает.
1. Я написал вам, что мешает сделать возможность использовать функциональность конкретной СУБД при внедрении, хотя бы те возможности, которые не противоречат встроенному языку (например кореллированные подзапросы). До версии платформы 8.2 можно было использовать несколько полей в условии В соединения. В 8.2 это обрубили. По поводу ROW_NUMBER тоже хотелось бы комментарий увидеть.
2. Такие библиотеки как node.js никогда бы не появились, если бы не появились среды исполнения javascript с бинарной трансляцией. В свое время в УПП появилась «оптимизация» корректировки стоимости на временных таблицах. РАУЗ в УПП и партии в ERP уже полностью на временных таблицах. Если бы не было проблем с производительностью встроенного языка — такое извращение никогда не появилось бы.
4. Логика СУБД это не только хранимые процедура, а выполнение разных расчетов на сервере. Из-за низкой производительности встроенного языка многие вычисления действительно выгоднее загнать во временные таблицы на сервер баз данных и затем вернуть результат.
5. Я неправильно написал вопрос, вы как бывший сотрудник MBS должны помнить, чем отличается интернационализация в Navision от Axapta. Вот хочется как в Axapta,

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

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

До версии платформы 8.2 можно было использовать несколько полей в условии В соединения. В 8.2 это обрубили.

Можете привести пример запроса? Боюсь, что не понял вопроса.

По поводу ROW_NUMBER тоже хотелось бы комментарий увидеть.

Я правильно вас понял — вы предлагаете ввести в язык запросов функционал, который будет работать только в MS SQL и не будет работать в других СУБД?

2. В свое время в УПП появилась «оптимизация» корректировки стоимости на временных таблицах. РАУЗ в УПП и партии в ERP уже полностью на временных таблицах. Если бы не было проблем с производительностью встроенного языка — такое извращение никогда не появилось бы.

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

4. Логика СУБД это не только хранимые процедура, а выполнение разных расчетов на сервере. Из-за низкой производительности встроенного языка многие вычисления действительно выгоднее загнать во временные таблицы на сервер баз данных и затем вернуть результат.

Вы имеете в виду — вместо реализации логики на встроенном языке она реализуется в виде запросов к СУБД?

5. Я неправильно написал вопрос, вы как бывший сотрудник MBS должны помнить, чем отличается интернационализация в Navision от Axapta. Вот хочется как в Axapta

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

Вообще зря я все это написал, это официальны блок и вряд ли вы ответите что-то отличное от того, что отвечаете на партнерке

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

Теперь ответы на вопросы:
1.1. до 8.2 была возможна следующая конструкция
СОЕДИНЕНИЕ Таблица1 КАК Строки1
ПО (Поле1, Поле2) В (
ВЫБРАТЬ ПЕРВЫЕ 1
Поле1, Поле2
ИЗ Таблица1 КАК Строки2
УПОРЯДОЧИТЬ ПО
Поле1, Поле2)
это не работало на всех СУБД кроме SQL Server. В 8.2 (видимо решили, что это унизит Oracle) эту возможность обрубили и оставили возможность использовать только одно поле.
1.2. Получение номера строки выборки:
SQL Server, ROW_NUMBER, 2005
Oracle Database, row_number() over()
IBM DB2, row_number() over()
Postgre, row_number() over()
Похоже что только на файловой нет
Еще более веселая штука, связанная с регистрами сведений. В базу добавляется поле _SimpleKey, которое является идентификатором записи регистра сведений и которое используется в механизмах платформы. Но во встроенном языке к нему доступа нет. А теперь представьте себе размер извращения, чтобы для каждой строки запроса получить последнее значение ресурса регистра сведений, имеющего несколько измерений.
2. Если вы будете продолжать делать упор на то, что производительность встроенного языка не важна — так и пишите в книге по встроенному языку — «это не язык, а скрип и необходимо минимизировать его использование. А если нужно что-то посчитать — внешние компоненты вам в помощь».
4. Именно, дошло до того, что многие разработчики, даже опытные, насмотревшись примером из ERP 2 начинают использовать временные таблицы вообще везде. Вообще это пошло еще с ЗУП 2, когда запросы на несколько тысяч строк стали нормой, опять же из-за низкой производительности встроенного языка, которая на задачах расчета зарплаты отразилась наиболее остро

Вообще на партнерке вам пишут очень много дельных предложений и замечаний, но на большинство из них идут либо «пожелание записано», либо «мы считаем что этого не нужно». По поводу «скорости» реализации пожеланий приведу 2 примера:
В 2005 году впервые подняли вопрос о необходимости использования merge при сравнении/объединении конфигураций. Данная функция появилась в 2014 (9 лет).
В тестовой версии 8.3.7 (2015 год) появилось динамическое обновление клиент/серверной базы без перезапуска конфигуратора — у нас люди плакали от счастья, хотя проблему стали обсуждать сразу после выхода платформы (2004 год)
По таким вопросам как ООП, производительность встроенного языка, развитие языка запросов должны быть постоянно открытые топики на партнерке с обсуждением всех заинтересованных сторон. Сейчас разработчики типовых конфигураций вообще не участвуют в топиках по платформе (видимо это у вас запрещено правилами внутреннего распорядка).
Ваша платформа, не смотря на ее технологичность без типовых конфигураций никому не нужна.

Это утверждение можно смело отнести к большинству платформ, аналогичных «1С: Предприятие». Бизнесу (в массе своей) не нужен инструмент разработки бизнес-приложения как таковой — ему нужно бизнес-приложение, решающее его, бизнеса, задачи. Поэтому мы делаем и платформу, и типовые конфигурации.
А платформу как таковую для создания тиражных конфигураций для различных областей бизнеса используют партнеры; то, что 1С-совместимых конфигураций создано более тысячи, говорит, на мой взгляд, о соответствии платформы решаемым ей задачам.
Если в компании нет 1С, без качественной конфигурации, покрывающей хотя бы половину потребностей — она там не появится.

Не всегда это так; например, в компании Вкусвилл система управления написана на 1С с нуля.

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

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

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

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

1.1. до 8.2 была возможна следующая конструкция
СОЕДИНЕНИЕ Таблица1 КАК Строки1
ПО (Поле1, Поле2) В (
ВЫБРАТЬ ПЕРВЫЕ 1
Поле1, Поле2
ИЗ Таблица1 КАК Строки2
УПОРЯДОЧИТЬ ПО
Поле1, Поле2)
это не работало на всех СУБД кроме SQL Server. В 8.2 (видимо решили, что это унизит Oracle) эту возможность обрубили и оставили возможность использовать только одно поле.

Вы уверены, что это не работает в 8.3?
Я только что попробовал — вот такой запрос (с условием соединения идентичным, если не ошибаюсь, вашему) работает на демо-базе.
ВЫБРАТЬ
    УчетНоменклатуры.Номенклатура,
    УчетНоменклатуры.Склад,
    УчетНоменклатуры.Количество,
    Валюты.Ссылка
ИЗ
    РегистрНакопления.УчетНоменклатуры КАК УчетНоменклатуры ЛЕВОЕ СОЕДИНЕНИЕ 
    Справочник.Валюты КАК Валюты ПО

    (УчетНоменклатуры.Номенклатура, УчетНоменклатуры.Склад) В
            (ВЫБРАТЬ ПЕРВЫЕ 1
                УчетНоменклатуры.Номенклатура,
                УчетНоменклатуры.Склад
            ИЗ
                РегистрНакопления.УчетНоменклатуры КАК УчетНоменклатуры
            УПОРЯДОЧИТЬ 
            ПО УчетНоменклатуры.Номенклатура,
                УчетНоменклатуры.Склад) 


1.2. Получение номера строки выборки:
SQL Server, ROW_NUMBER, 2005

ROW_NUMBER() не работает в SQL2000, а мы его до сих пор поддерживаем.

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

Такого не утверждалось. Говорилось, что ситуаций, где производительность именно встроенного языка становится критичной — сравнительно немного. Мы такие ситуации анализируем.

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

У вас есть доступ в партнерский форум? Открывайте топики, устраивайте дискуссии, мы только «за».

Сейчас разработчики типовых конфигураций вообще не участвуют в топиках по платформе

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

Не всегда это так; например, в компании Вкусвилл система управления написана на 1С с нуля.

Назовите разработанную с 0 конфигурацию по сложности и функциональности сопоставимую с ERP 2 или хотя бы УПП.
Мы это делаем — вот, вот, и вот, и еще много другого

Уж расширения точно сделаны не для внедренцев. Это механизм, необходимый для полноценной работы другой вашей мечты — работе в облаке. Для проектов внедрения — никак не пригодится. А уж про выгрузку конфигурации в файлы не стоило упоминать. Вас давно просили сделать, чтобы при выгрузке отслеживались версии файлов, что на порядки могло бы ускорить выгрузку/загрузку. В 1cpp для платформы 7.7 это работало и прекрасно использовали платформу с хранилищами на SVN. Сейчас одна надежда на ET.
Делать так — значит ступать на очень скользкую дорогу, что весьма рискованно как для нас, так и для партнеров и внедренцев.

Один из вариантов — не давать сертификат 1С: Совместимо для конфигураций, которые используют такие конструкции. Это хоть какой то выход.
Я могу вам сказать, что система оперативного учета на платформе 7.7 SQL с использованием 1cpp и ToyBlocking даст огромную форму платформе 8.3 в части производительности, учитывая например возможности использования индексированных представлений.
Вы уверены, что это не работает в 8.3?
Я только что попробовал — вот такой запрос (с условием соединения идентичным, если не ошибаюсь, вашему) работает на демо-базе.

Попробуйте использовать в () поля из присоединяемой таблицы, а в подзапросе тоже выбирать данные из присоединяемой таблицы, а не из основной и все встанет на свои места
ROW_NUMBER() не работает в SQL2000, а мы его до сих пор поддерживаем.

Я повторюсь, вы могли бы сделать для SQL2000 реализацию на основе полного соединения, может и стимул появился бы у пользователей для перехода на более новые версии. Ведь прошло 15 лет. У нас многие клиенты с 7.7 работают на SQL 2008 (правда не совсем документированным способом)
У вас есть доступ в партнерский форум? Открывайте топики, устраивайте дискуссии, мы только «за».

Таких топиков полно, только без участия разработчиков платформы и конфигураций. Смысл?
В прошлом году подняли вопрос о том, чего не хватает в платформе. Не хотите обсудить, что из этого сделали? А судя по извращениям разработчиков типовых — лестница между этажами закрыта и лифты не ходЮт.
Назовите разработанную с 0 конфигурацию по сложности и функциональности сопоставимую с ERP 2 или хотя бы УПП.

А есть потребность в конфигурациях такого масштаба? Можете привести пример? Я серьезно, вопрос не праздный.

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

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

Почему так считаете? Мы переносим в расширения все больше и больше объектов. Уже видел случаи переноса внедренцами части модификаций на местах в расширения с целью облегчить переход на новые версии. Что может помешать использовать расширения внедренцам? Пока — малое количество объектов, поддерживаемых расширениями. Но их будет все больше. Так что проблем не вижу. Если их видите вы — опишите пожалуйста.

Один из вариантов — не давать сертификат 1С: Совместимо для конфигураций, которые используют такие конструкции. Это хоть какой то выход.

У меня есть некоторый опыт написания платформ для нескольких ERP (не связанный с 1С). Могу сказать по своему опыту — введение такой «полуподдерживаемой» функциональности в платформу через пару версий их активного использования прикладными разработчиками приводит к проблемам в поддержке и развитии платформы, которые сводят на ноль все преимущества этой функциональности. Это даже если платформа не публичная и ее используют только прикладные программисты внутри компании. Если же платформа публичная, как у 1С — количество неприятностей можно смело возводить в квадрат (а то и в куб).

Попробуйте использовать в () поля из присоединяемой таблицы, а в подзапросе тоже выбирать данные из присоединяемой таблицы, а не из основной и все встанет на свои места

Можете написать такой запрос для демо-базы, который работает на 8.1 и не работает на 8.3?
Мне действительно интересен этот вопрос — «отваливают» функциональность довольно редко, хотелось бы разобраться.

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

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

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

Да потому что на проектах внедрения никогда не было проблем с новыми объектами или реквизитами. Как например ваши расширения помогут, если для реализации требований клиента необходимо внести изменения в типовой функционал (модули), который потом будет обновляться?
введение такой «полуподдерживаемой» функциональности в платформу через пару версий их активного использования прикладными разработчиками приводит к проблемам в поддержке и развитии платформы

Повторюсь, на проектах внедрения (не только 1С) всегда есть этап Performance Tuning, то есть тонкая настройка системы для конкретного клиента. Ваша платформа таких возможностей не предоставляет, что по мнению многих разработчиков 1С — плохо. Кроме того, требования конечного пользователя гораздо более детальные чем маркетинговые требования массового продукта, что может потребовать нестандартных решений. Ваша платформа таких возможностей не предоставляет.
Можете написать такой запрос для демо-базы, который работает на 8.1 и не работает на 8.3?

ВЫБРАТЬ
Товары.Ссылка,
ЦеныТоваров.Цена
ИЗ Справочник.Номенклатура КАК Товары
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК ЦеныТоваров
ПО
(ЦеныТоваров.Номенклатура, ЦеныТоваров.ТипЦен) В (
ВЫБРАТЬ ПЕРВЫЕ 1
Подчиненные.Номенклатура,
Подчиненные.ТипЦен
ИЗ РегистрСведений.ЦеныНоменклатуры КАК Подчиненные
ГДЕ
Подчиненные.Номенклатура = Товары.Ссылка
УПОРЯДОЧИТЬ ПО
Период
)

Проверять нужно на клиент-серверной базе SQL Server УПП 1.2-1.3. На файловой базе 8.1 валится с ошибкой, на платформе 8.3 в режиме совместимости 8.1 выдает ошибку, как без режима совместимости
О каком вопросе речь, напомните пожалуйста. Возможно я не в курсе.
Ну и надо помнить что год — не то чтобы очень большой срок для софтверного проекта в миллионы строк кода.

Сделайте поиск — «опрос по средствам разработки». Оказывается опрос был в начале 2013 года, то есть почти три года прошло.
поэтому я и написал, что разработчикам платформы нельзя отмежеваться от разработчиков флагманской типовой конфигурации, что вы пытались сделать несколько постов назад

Где я такое писал? Дайте пожалуйста ссылку или цитату.

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

Про это рассказывали на октябрьском семинаре.

Повторюсь, на проектах внедрения (не только 1С) всегда есть этап Performance Tuning, то есть тонкая настройка системы для конкретного клиента. Ваша платформа таких возможностей не предоставляет

Конфигурация предоставляется в исходных кодах. Есть «Замер производительности» в Конфигураторе, есть КИП — можно выявить узкие места, поменять исходный код и свойства объектов конфигурации.

Проверять нужно на клиент-серверной базе SQL Server УПП 1.2-1.3.

Спасибо, теперь понял, о чем речь.
Да, такое поведение платформы исправили в 8.2 (если не ошибаюсь — 8.2.14, «Запрос, содержащий оператор В с множественными операндами, в подзапросе которого есть упорядочивание, может быть исполнен, если из подзапроса нет обращений к полям внешнего запроса.», есть в V8Update.htm). Исправление было сделано в рамках унификации работы с СУБД, т.к. предыдущее поведение не работало на всех СУБД.
Ваш запрос можно модифицировать так, чтобы он заработал на 8.2:
ВЫБРАТЬ
Товары.Ссылка,
ЦеныТоваров.Цена 
ИЗ Справочник.Номенклатура КАК Товары
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК ЦеныТоваров
ПО
(ЦеныТоваров.ТипЦен) В (
ВЫБРАТЬ ПЕРВЫЕ 1
Подчиненные.ТипЦен
ИЗ РегистрСведений.ЦеныНоменклатуры КАК Подчиненные
ГДЕ
Подчиненные.Номенклатура = Товары.Ссылка
УПОРЯДОЧИТЬ ПО
Период)


Сделайте поиск — «опрос по средствам разработки». Оказывается опрос был в начале 2013 года, то есть почти три года прошло.

Сделал, посмотрел. Все 10 страниц читать не стал, пробежал первые три. Часть пожеланий реализована в Enterprise Development Tools (но тут придется подождать его готовности). Были пожелания ускорить работу с хранилищем конфигураций — работаем в этом направлении, почти каждую версию платформы есть доработки в этом направлении.
Надеюсь, не будете обвинять нас в том, что мы не реализовали ВСЕ пожелания из опроса?
Где я такое писал? Дайте пожалуйста ссылку или цитату.

Вы ставите приоритет на функциональность платформы, а не на способы реализации типового решения
Про это рассказывали на октябрьском семинаре.

повторюсь, это все маркетинговые возможности к реальным внедрениям не имеющие никакого отношения
Ваш запрос можно модифицировать так, чтобы он заработал на 8.2:

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

Дайте пожалуйста ссылку или цитату. Не припоминаю, что я писал подобное.

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

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

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

Можете поверить на слово. После выходя очередной версии платформы я внимательно читаю весь список изменений и сразу определяю для себя возможности их использования на реальных проектах
Подобные высказывания от вас как раз подтверждают то, о чем я написал в habrahabr.ru/company/1c/blog/269611/#comment_8644699. У вашего руководителя есть новые бизнес-идеи (работа в облаке, интерфейс Такси и т.п.). Именно их запросы вы и реализуете. То как это будет использоваться в типовых решениях или у клиентов вам мало интересно. Посмотрите сколько вопросов по платформе накопилось за последние 2 года на партнерском форуме без внятного ответа. Раньше такого безобразия не было. И партнерский семинар и ваш выход на площадку habrahabr это чистый пиар, без желания получить обратную связь
Согласен, коррелирующие подзапросы непосредственно в тексте запроса были бы удобны. Сейчас такие задачи приходится решать через временные таблицы. Но тут мы приходим к стандартной задаче в жизненном цикле большого софтверного продукта. Есть запрос на новую функциональность (коррелирующие подзапросы). При этом задача, для решения которой требуется эта новая функциональность, уже решается существующей функциональностью (временными таблицами), пусть и не так изящно. А еще у нас есть список других запросов на новую функциональность, в том числе и ту, которая решает задачи, до сих пор решения в рамках системы решения не имеющие.

Этим абзацем я иллюстрировал методику расставления приоритетов (новая функциональность, позволяющая решать НОВЫЕ задачи vs. новая функциональность, позволяющая решать задачи, уже имеющие решения в рамках существующей функциональности). Иногда первый тип новой функциональности получает более высокий приоритет, т.к. расширяет функциональность системы в целом; иногда — наоборот.

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

Коллега, есть идеи стратегические (работа в облаке, веб-клиент, мобильная платформа и т.п.). Без их реализации через некоторое время фирма будет обойдена конкурентами, лишится прибыли, снизит как следствие затраты на разработку, и в итоге станет хуже всем — и фирме, и партнерам/внедренцам, и клиентам. Не реализовывать стратегические идеи мы не имеем права.
Есть идеи тактические (импорт содержимого файлов в форматах Microsoft Excel 97-2010 и OpenDocument в табличный документ, использование логических выражений в описании поля выборки и в выражениях фильтрации результатов запроса (предложение ГДЕ), использование функций и временных таблиц при работе с внешними источниками данных и т.д. и т.п) — их мы тоже реализуем. Я сожалею, честно, без дураков, что та функциональность, которая необходима лично вам, до сих пор не реализована.

И партнерский семинар и ваш выход на площадку habrahabr это чистый пиар, без желания получить обратную связь

Не скажите. Несмотря на что, что на Хабре мы недавно, уже от нескольких пользователей получили в личную переписку полезный фидбэк, который планируем использовать в работе. Про семинар даже и не говорю.
Как пользоваться SCOM? Какие классы реализованные в 1с можно использовать во внешней компоненте?
Как библиотеки реализованные в 1с можно использовать во внешней компоненте?
Есть ли какие то примеры использования данной техники от и до.
Добрый день. SCOM сделан для внутренних нужд — штатного способа использовать его вне платформы нет. Точнее есть — когда Вы используете COM-внешние компоненты, взаимодействие с SCOM очень прозрачное)
Спасибо! Я переформулирую свой вопрос: требуется внешняя компонента (native), дающая возможность использовать регулярные выражения и передавать файлы по SFTP. В текущих версиях платформы таких возможностей нет, но описанные в статье библиотеки — ICU и cURL — это могут.

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

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

Спасибо вам за обстоятельный ответ. Объяснение причин тех или иных решений положительно сказываются на понимании системы. Пожалуйста, продолжайте в том же духе!
По поводу regex: почему бы не использовать стандартный из C++? Или у вас там что-то сверх предлагаемых стандартной библиотекой возможностей?

По поводу sftp — libcurl можно (лицензия MIT) и нужно (надёжнее) прилинковать.

Есть и множество других возможностей типа Boost.Asio/Boost.Regex.

ICU линковать, конечно, перебор, она огромная.
Если начинать писать что-то сегодня, сейчас, то да — std::regex неплохой выбор. Но это сегодня…

У стандартного regex'а есть одна, но очень серьёзная проблема: он и в стандарте появился не так давно (в 2007 году), а в компиляторах — так и совсем недавно (в GCC 4.8 точно ещё поломан, в MSVC тоже не то до версии 2012, не то до версии 2013 проблемы были).

А так всё хорошо, да…
вообще, на дворе 2015й год уже, колоний вот-вот закончится, скоро выпустят c++17, gcc уже версии 5.3, а vs версии 2015 upd 1, и даже к 2013 уже пять апдейтов выпустили, более того, vs 2015upd1 поддерживает кросс-платформенную сборку с помощью clang, а gcc уже многие признают deprecated, а вы все в 2007 году живёте, не стыдно?

и даже для таких ретроградов есть Boost.Regex для c++03
и — очнитесь — в современном c++ 2007 — каменный век, сейчас многие вещи из c++11 устаревшими считаются
Не знаю у кого там «многие вещи из C++11 устаревшими считаются». В мире тяп-ляп-стартаперов — может быть. А серьёзные проекты только-только начинают переход на C++11. Вот, например. Обратите внимание на дату.
тяп-ляп-стартаперы — они вообще больше по всчким рубям и эликсирам со скалами

ну да ладно.

давайте об устаревшем в c++11.
одна из самых главных устаревших фич — это std::bind вместе со всеми этими bind1st, bind2nd.
bind'ы устарели, в принципе, еще не успев появиться в стандарте c++11. потому что лучше пользоваться лямбдами. и это только то, что в пределах одного стандарта. с переходом на c++14 и 17 еще несколько вещей явно депрекейтятся, а несколько не будут рекомендоваться.

что касается хромиума: переход на новый стандарт задерживался в виду поддержки устаревших операционных систем, компиляторы под которые не в полной мере поддерживали нужные фичи из c++11/14 (практически можно считать их одним стандартом). сейчас вышли vs2015 и clang с cxxabi под все существующие платформы присутствия chromium, вот и все дела. на ближайшее время у них запланирован отказ от поддержки XP и старых ядер линукса, там уже будет разрешён полный набор c++14.

не стойте на месте, изучайте новое в языке, все основные компиляторы сейчас поддерживают не просто всё из c++14, а даже бОльшую часть из c++17, clang так вообще всё, msvc отстает по sfinae и constexpr, gcc почти всё кроме прав деталей, ну и он вообще скоро будет объявлен deprecated на многих платформах (clang во все поля).

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

Изучать и пробовать — это одно. А вот выкидывать работающий код — это совсем другое. О чём я, собственно, и сказал. И о чём написаны десятки статей. Если вы не видите между двумя вещами разницы — то это значит, что вы никогда не руководили разработкой крупных проектов.

Что касается std::bind'ов или, тем паче, std::auto_ptr — то это просто были мертворождённые творения, я, в общем, и не знаю никого кто ими вообще когда-либо пользовался. Но даже если в вашем проекте это случилось… в этом случае я бы не стал переписывать код, где они используются: да, это — весьма угрюмое порождение «коллективного разума», но проблема не в том, что они не работают, а просто в том, что ими не очень удобно пользоваться.
Не выкидывать рабочий код, а оставлять, применяя новые фичи и постепенно переписывая. А не тупо отказываться от новых фич.

Изначально ваш вопрос был: как написать либу для 1C Native API с regex. Я предложил использовать из C++11. Вы начали вспоминать про 2007-й год. Либу вы пишете в 2007-м или в 2015-м?
Либа может хотеть код, который уже написан. ICU — достаточно распространённая библиотека и её много кто использует, в том числе и для regexp'ов. В то же время она довольно-таки большая, так что вполне может хотеться не тащить её с собой. Причём тут 2015й год и необходимость переписывать всё и вся?
Не передёргивайте, icu тащить не нужно, можно взять boost.regex.
Можно. Но если бы ICU предоставлялась как часть системного API, то было бы логичнее использовать её: приложение было бы меньше и работало бы не хуже.

Откуда такая странная любовь ко всему «новому и блестящему»? Как сороки, чесслово. Всё зависит от задач, выбирать технологию только потому что она прописана в какому-то там «стандарте» — попросту глупо…
Не стойте на месте, развивайтесь. А то я встречал старпёров, которые говорили «И не увлекайся этими лямбдами, они непонятные и не нужны вовсе». А на самом деле просто не хотят ничего нового изучать.
Добавлю, что старые платформы разработки (под Windows в частности):
1) убивают производительность. Пример: на новых XEON сервер 1С работает медленнее!!!, чем на старых (нет оптимизации при сборке?).
2) выносят мозг глюками. Пример: модальные окна в RDS.
Sign up to leave a comment.