Comments 23
не нужно впутывать государство
Да, бухгалтерию придумал Лука Пачолли. Но как это выглядит в конкретных деталях жестко определяет именно государство. И если в правительстве у кого-то зачесалось изменить дизайн шапки документа, зачем это должна оплачивать вся остальная страна?
В свете имеющихся тенденций ИМХО стоит всю мелкоту (до 100-500 душ) пересадить в облако, курируемое непосредственно ФНС. Да, одноэсникам это вряд ли понравится, но производительность труда в стране должна вырасти. У т.н. "вертикальной структуры власти" есть свои преимущества, однако, и их надо использовать.
У 1С сейчас и так всё хорошо. Иностранные конкуренты кто сами ушли с рынка, кого вытеснили в угоду импортозамещения. Какой им смысл что-то ломать, переделывать, выкладывать в Open source?
На данный момент десятки, а может сотни тысяч программистов пишут на архаичном языке 1С. Вы думаете они жаждут его забыть и переучиться на Java? Я знаю людей, которые "собаку съели" на 1С7, продолжают поддерживать на ней проекты, и даже пописывают новые. А что, системные требования минимальные, а основной учётный функционал там есть. Что не хватает - можно дописать на тех же Delphi или чем угодно по вкусу.
Попробуйте 1С:Элемент и его язык. Он похож на язык платформы 1С, но имеет ряд изменений и улучшений, в частности статическая типизация, большое количество фич из коробки (те же регулярки), облачная IDE на базе Teya, схема упрощения синтаксиса как в питоне. А еще все элементы и формы проекта в yaml файлах с возможностью прямого редактирования их кроме визуального конструктора свойств. Я лично год пишу на Элементе и тащусь от него, особенно когда приходится возвращаться обратно на платформу 1С.
Да, и работа с классами в целом тоже имеется в виде структур, только пока без наследования и полиморфизма, но хотя бы методы и поля имеются с управлением видимостью методов. Для задач сериализации например из JSON текста в объектную модель на ходу идеально заходит.
Можете рассказать подробнее, что именно вы на Элементе пишете, какие задачи решаете?
По сути сейчас использую Элемент как расширение имеющихся возможностей платформы в части мобилок удобных и красивых, в части ЛК, веб-сервисов для реализации микросервисной архитектуры. Есть пара проектов полностью автономных для задач чисто учета (то же самое что и на платформе, только в вебе и быстрее, а еще дешевле по лицензиям), ну и какие то сложные сценарии интеграции, где веб сервис на Элементе выступает в качестве брокера или просто для вебхуков.
Можно, конечно, и полноценную CRM сделать, но тут наверное какую-то специфическую надо реализовывать, так как сложно тягаться с общими решениями типа амо, битрикса, ритейла. Хотя за Элементом преимущество в части открытого исходного кода и возможности кастомизировать решение под себя, тут взято лучшее от самой платформы.
А вот это дельный ответ, в отличие от большинства. Респект. Не слышал, ставлю в план, испробую как будет время.
Почему облачность среды разработки преподносится как преимущество? Браузер вообще штука кривая, сложная и не надёжная, так ещё и зависеть от интернета при написании кода? По мне минусов гораздо больше, чем мнимых плюсов.
Язык java становится основным языком программирования.
Бхаха
Подавился печенькой
А кому и чем мешает 1С? Если платформа негодная - от неё рано или поздно откажутся же...
Работал 7,5 лет с 1c. Потом перешёл на Oracle и SAP, но с 1с встречался почти на каждом проекте. У неё на самом деле лучший TTM и минимальная стоимость изменений, поддержки. С масштабируемостью тоже всё в порядке. Прекрасная поддержка российских требований из коробки.
А ещё самый крутой UI/UX, если забыть про мобилку.
Основной минус - детализация процессов. Например, в процессе закупки на стороне Oracle раз в 5 больше шагов, чем в 1С и можно приделании дополнительные докинуть.. Но не всем это надо. Из плюсов у 1С всё отлично с управлением денежным потоком. Когда решение платим или нет принимается не на основе ранее возникших обязательств, а в момент оплаты. И ещё есть куча специализированных решений от партнёров. Для фермы, для молочного комбината, для автомастерской и пр.
А на Java переходить не надо. Сейчас платформа предметно ориентирована вместе с языком и это нормально. С асинхронными интеграциями тоже норм.
1С это русский Кобол. Хрен когда умрёт, как и проекты на нём.
Полагаю инженерно правильным вариантом будет продолжать совершенствование конфигуратора в проекте EDT и дополнить его языком java (как минимум). Реализация такой задачи сразу подымет платформу на недосягаемый уровень в сравнении с конкурентами не только в стране, но и в мире.
Еще в начале 2000-х когда 1С 8.0 только анонсировали, я очень надеялся что 1С откажется уже от самопального языка, а возьмут ту же java. Тогда выбор языков был гораздо меньше.
C# тогда только появился, хотя вариант тоже был бы хороший. Выгоды по моему очевидны, но увы руководство 1С их не увидели и не хотят видеть до сих пор.
Спешу вас обрадовать: регулярки в платформу-таки завезли😁
А в чем заключаются плюсы перехода на Java?
Кратко в заметке всё указано. Попробую детализировать.
Джава дает:
больше возможностей для объектного программирования (сказано в тексте);
позволяет использовать наработанное человечеством вместо выморочно-доморощенного; последнее было обосновано и хорошо работало пока java была в нулевых тяжеловесна и в поисках пути; помню я тогдашние приложения - едва ворочались; теперь она по скорости и средствам в передовиках;
легче будет подключать сторонние наработки, например, внешние базы данных; делать прямо из модулей без внешних компонент или web-сервисов (то, кстати, в заметке указано, но кратко); нынешнее подключение мрачное убожество, проще сделать свой web-сервис (что сделано у меня);
как частность - удобная работа с многострочными текстами запросов взамен имеющейся архаики; кстати, джава сама от подобного избавилась лишь в последние годы;
меньше будет дублирующего, индийского кода; легче будет обмениваться кодами между различными проектами (без тупого дублирования).
По факту я описываю современное IDE с джавой, у которого кроме редактора есть конфигуратор в виде закладки с одинэсными мастерами форм, отчетов и своих запросов и которое кроме подключения сторонних пакетов подключено к специализированным пакетам своей среды - к метаданным. Эдакий вариант NetBeans или Интележи Айдиа. Обе среды позволяют в современных компах навешивать чертову уйму плагинов и работают шустро. Стерпят и плагин конфигуратора.
Не потребуются костыльные средства обработки строк (тоже сказано в заметке), тяжеловесные парсеры и конструкторы xml и html и то же самое для бинарных данных и всякое такое.
Вообще-то, я этот текст написал не столько для разрабатывающих на платформе 1С, сколько для разрабатывающих саму платформу, если, конечно, там еще кто-то остался, кого можно назвать разработчиком. Пока все выглядит как некая вялая сдельщина для удовлетворения требований высших манагеров, ориентированных исключительно на бабки.
То есть вбрасываю идею. Судя по основной массе реплик подобное большинству в голову не приходило. Вот пусть теперь идея носится в воздухе пока не найдёт свою группку чертовски талантливых сорвиголов, которые завращают Землю как надо.
Примерно так. Компране ву, мон ами?
Да вроде бы всё понятно, но...
больше возможностей для объектного программирования
Ну кроме того, что все уже привыкли к объектам, какие плюсы можно получить от объектного подхода в промышленной системе? В последнее время появилось большое количество статей о том, что объектный подход - это большая ошибка.
... позволяет использовать наработанное человечеством ...
а что сейчас мешает использовать? Можно запросто сделать cвою DLL и вызвать её когда надо. Опять же, если писать DLL на языке С (как это и задумано), то количество наработанного человечеством кратно возрастает.
легче будет подключать сторонние наработки...
а вот тут согласен, что подключение как DLL, так и внешнего JAR можно упростить. Опять же web сервисы можно будет проще использовать.
удобная работа с многострочными текстами запросов...
как вы сами правильно подметили - это частность, всего лишь вопрос привычки. У той же Java многострочные запросы никуда не делись, просто теперь надо писать 3 кавычки вместо одной. И в той же Idea, очень часто, чертыхаясь, заменяю 4 кавычки (да здравствует автозамена) на 3 кавычки. Я бы не сказал, что это очень удобно.
меньше будет дублирующего, индийского кода...
вот эта вещь никак не связана с используемым языком, а зависит только от программиста и его уровня.
И да, вы правильно написали, что пытаетесь описать современную IDE с языком общего назначения в привязке к 1С, которая является узкоспециализированной платформой со своим DSL. Но вот вопрос "зачем?" остается.
Как-то не видно плюсов...
А вот минусов вижу несколько:
интеграция чужого языка в свою разработку приведет лишь к усложнению платформы и снижению надежности. Возникают вопросы ответственности, и они становятся особенно интересны на границах зон модулей.
чтобы было удобно использовать Java - всю объектную модель платформы 1С надо будет переписать.
для обеспечения обратной совместимости надо будет тянуть 2 языка и 2 объектные модели.
внедрение Java автоматически увеличит требования по ОЗУ и по процессору.
И это только на первый взгляд.
Про просто работы с XML лучше и не вспоминать. И сложность эта связана именно со сложностью стандарта самого XML, а никак не используемого языка и библиотеки.
Ну и опять же, в защиту 1С - это коммерческая компания, созданная с целью заработка. И вот с позиции разработчика я пытаюсь понять, что же такого я получу после внедрения Java (ну или другого языка, например, Rust) в свою систему?
Упроститься ли жизнь прикладного программиста? Нет, не упроститься. Прикладной программист решает прикладную задачу и ему все эти объектные подходу побоку.
Упроститься ли жизнь системного разработчика в 1С? Нет, не упроститься. Теперь надо уметь разбираться в Java, в её потрохах, как-то исправлять или обходить их ошибки. Отдельный вопрос миграции всего при смене версии Java... ну такое себе.
Упроститься ли жизнь тех.поддержки 1С? Ну тут даже не знаю что писать... как узнать какая версия объектной модели используется (старая или новая) у простого пользователя?
Будет ли лучше компании 1С? Сомнительно, ибо затраты будут исчисляться в человеко-годах, вой о кривизне и программистов будет слышен на Марсе, вой об их тех.поддержке будет слышен на Юпитере... А денег за это больше взять не получиться.
И вот анализируя всё это у меня в голове звучит всего лишь один вопрос: А зачем?
Вы серьезно подходите к теме и не ответить также развернуто невозможно. Вы пробудил демона моего воображения.
Начну с простого, которое отражает как в зеркале общее явление. С порочности объектного подхода и в прикладном программировании в том числе. Начать стоит с понимания предмета. Объектный подход это распределение свойств и методов по категориям или группам, или контейнерам, или пространствам имен - на выбор. Последний термин ближе к области рассмотрения. Если методика порочная, наверное альтернативная выгоднее. Что является альтернативой? Тут не надо быть программистом (айтишником), достаточно нормальной логики - альтернативой является бессистемность, мешанина, хаос и порядок виден только индивиду-создателю. Проблема делано путанная и рассчитана на поверхностное восприятие реальности. Что любопытно, совсем недавно подобная дискуссия возникла с коллегами, которые что-то там прочли о предпочтении "функционального программирования" объектному подходу. На вопрос, что есть функциональное программирование ответить четко не сумели, но описали как использование только функций, а данные либо разрозненны, либо упорядочены в наборы. В джаве этому соотвествуют записи и перечисления, в Паскале тоже, кажется, записи, в OdinAss'ke вроде тоже есть подобное. Ну еще разные коллекции или массивы. Объяснить, что этот подход является частным случаем объектного не удалось. Хитренько (по-ленински) улыбались и покачивали головками. В мире, кстати, для "функционального программирования" тоже нет устоявшегося определения. Объектный подход реализует эту методику как частность. На джаве создаем в классе статические методы и работаем со статическими полями или переменными. Более того, глубинная реализация нестатического метода класса содержит скрытый параметр со ссылкой на экземпляр. Это хорошо видно в технологиях отражений джавы (invoke, TMethod). То есть имеем характерный пример путаницы частного и общего, что встречается повсеместно не только в быту, но и на всех уровнях до самых значимых, например, противоречия между трудом и капиталом в современном мире или решение основного вопроса философии и сейчас и век назад. Вспомните историю написания "Материализма и эмпириокритицизма". То же самое - спутывание частного и общего, лично-чувственного и объективно-материального.
Теперь об объектности в 1С. Она объектна. Хотя язык не типизирован, но все переменные в нем могут быть как простыми данными, так и сложными объектами. Это объекты конфигурации, описание метаданных, прикладные объекты вроде коллекций или обработчиков внешних данных вроде гипертекстов, просто текстов или бинарных файлов. Для каждого типа созданы в сущности неплохие решения как и в других языках высокого уровня, но с каждым годом (который в IT лучше считать десятилетием обычной жизни) эти решения все более и более архаичны и программирование на встроенном языке 1С становится сектантством, хотя и весьма многочисленным. Оно никогда не выползет за пределы своего желтенького домика. А вот использование другого языка с широким спектром применения открывает двери в большой мир. Пусть это будет не джава, а питон или пресловутый Rust, о котором в последние недели начали трепаться. Если в них достаточно универсальных наработок - ради бога. Однако, сдается мне, что джава универсальнее. Она отлично реализует серверные приложения всяческих родов, десктопные, консольные и в ней нет ничего необычного, чего нет во встроенном языке Odin Ass. Те же переменные, массивы и циклы. Джава проверена четвертью века. Её и шарп не догоняет. Для всяких пресмыкающихся питонов и блескучих перлов есть свои ограниченные ниши (или загоны).
Удобство реализации объектов в джаве и javascript'e сильно раскрепощает в случае нетривиальных вычислений, избавляет от нудных повторений кода (индийский код). Но чтобы это себе хорошо представить необходим опыт программирования в обоих мирах. Простое утверждение не доходчиво. В 1с тоже можно на лету создать объект, но это будет вариант экземпляра финального класса из ограниченного набора классов, представленных в языке. То есть как раз та самая парадигма "функционального программирования". Вдобавок функция может быть отделена от данных весьма приличным структурным интервалом, что не может не сказаться на общей производительности труда разработчика. Понятно, что мусорить и плодить дублирующийся код можно и в самых идеальных условиях, но не будем впадать в досадные крайности.
Теперь о способе подключения сторонних наработок. В 1с-ке есть несколько вариантов интеграции, она является великолепным объединителем технологий. COM-объекты Windows напрямую, внешние компоненты по технологии OLE-automation или Native API, вызов программ непосредственно и использование web-сервисов. Все эти способы лично я юзал с начала нулевых. Внешние компоненты делал на Паскале, потому что родной Си стал уже слишком громоздок по сравнению с началом 90-х, когда на нем было работать легко и приятно, особенно объектном (С++). Все это не что иное как внешние DLL-ки. Для каждой надо затевать отдельный проект в другой среде программирования, а потом еще и подключать с различными ухищрениями. А теперь представим, как бы это подключение к чему-нибудь вне (пусть это будет какая-нить СУБД) было бы на встроенной джаве. Создаем одной командой соединение, другой - запрос, причем в многострочном литерале, третьей выполняем и потом организуем извлечение данных. Всё, ales. Как это выглядит собственными средствами 1С? В ней имеется внешнее подключение к сторонней СУБД. При этом надо создать в конфигуратора описание таблицы или представления с детализацией по полям. Произвольный запрос или командный блок не предусмотрен. Если создавать на лету (не помню, есть ли такое), то надо все это повторить программно. Весьма неуклюже. Как происходит с внешними компонентами или web-сервисами? Для начала надо напрограммировать в отдельном проекте либо общую технологию работы с произвольными запросами к внешней СУБД, либо решение просто частных расчетных задач. Потом подключить, что не совсем тривиально и зависит от клиент-серверной конфигурации. И наконец использовать в соответствии с придуманной параметризацией и дай боже, чтобы она оказалась не очень громоздкой. Наиболее выгодной технологией интеграции в настоящее время я считаю web-сервисы. Может, как-нибудь напишу статейку об этом в разрезе реализации на джаве. Но и для них мне пришлось создавать специальную обработку в качестве интерфейса, чтобы переложить обмен данными в формате json'a на привычную параметризацию процедур и функций и потом эту обработку переносить между конфигурациями, а чтобы это сработало должен быть запущен соответствующий прикладной web-сервер.
Как видите производительность очень сильно различны в этих подходах. А производительность это деньги. Поэтому мы плавно переходим к прикладникам и бизнесменам.
Разумеется, никто не хочет расставаться с привычной рутиной, хотя она становится все тягостнее и менее доходной. Программисты, которые природно поумней, бегут из ÓdinAss'ki в джаву или ВЕБ. Но таких не большинство. А система тем временем коснеет, дряхлеет и хуже реагирует на требования и наработки текущего момента. Как в фильме Феллини "И корабль плывет" - плывет, тихонько разлагаясь, к уже недалекому финалу. Сидят в уголках старички, обсуждая "интродьюсио", орёт какой-то басист, в трюме тихо тоскует в своих помоях несчастный бегемотик, там же кидает уголёк черная команда и толпы бездельников слоняются по всем палубам.
Разумеется, перевод на джаву потребует серьезного передела внутри платформы. Я это и не скрывал в заметке. Тут нужен государственный подход, пусть даже если это будет частный стартап. Надо мыслить в миллионах и парсеках, а это дано не только лишь каждому. Кто не мыслит масштабно, не имеет будущего, он скучен и его гроб зевая ждет. Правильным было бы данный проект запустить без шума как НИиОКР с хорошим финансированием, чтобы работали в нем идейные, мотивированные и энергичные и по выходу на добротный пилотный вариант обеспечивать совместимость с предшественниками.
Я уверен, что когда затевалась версия 1с-7 были такие же споры, потому что 6-ка отличалась кардинально, а 7-ка была как тот яростный взлет в 61-м. Потом она плавно эволюционировала до тупика и затем опять взлет с версией 8, в которой были качественные изменения, отвечающие эпохе WEB. Полной совместимости 7 и 8 нет, есть лишь конвертация и это нормально. Так и с проектом новой платформы должно быть. А вот язык можно и сохранить и даже реализовать одинэсную джаву, чтобы не прыгать с национального языка на английский. Всего-то делов что препроцессорная обработка с заменой слов. Кому на чем нравится, на том пусть и пишет: на архаике, чистой java, или адаптированной о́дин-джаве.
Аргумент, что джава-машина требовательна к ресурсам компьютера, не слишком серьезен. Слабый комп всегда можно ускорить твердотельным диском и дополнительной памятью. Теряют больше иногда, чем на такой модернизации.
Хотел еще порассуждать о способах реализации разных внутренних механизмов платформы вроде разных служебных модулей, пакетов, различением серверных и клиентских модулей, но это уже будет грехом суесловия. Все это вполне на джаве реализуемо. Думаю, можно использовать механизм аннотаций как раз для разделения кода сервера и клиента, а также просто флажки и неназначенные ссылки.
Примерно так
Ну так 1С:Исполнитель и есть "адаптированая 1С джава"
С демонами надо бороться.
Давайте, придерживаться общей терминологии - иначе обмен мнениями перейдет в эмоциональные изливания...
Термин ООП довольно четко описан. Кроме распределения данных по объектам (а скорее всего по классам) подразумевает использование наследования, полиморфизма и прочей ООП магии.
И почему вы решили, что альтернативой ООП подходу "альтернативой является бессистемность"? Разработчики ядра Linux наверняка будут с вами несогласны.
К сожалению, в программировании нет серебряной пули. Применение парадигмы ООП, или структурного подхода, или функционального - не означает однозначного превосходства хоть в чем-то по причине того, что программы пишут люди.
И в этом же кроется причина неопределённости "функционального программирования", несмотря на довольно четкие определения этого подхода. Именно люди вносят эту неопределённость, излагая своё виденье подхода. И да, в этот момент я "Хитренько (по-ленински) улыбаюсь".
Теперь об объектности в 1С.
Объектня модель в 1С идельна, ибо она выверена в течении (уже можно сказать) десятилетий... а учитывая что у нас год за десять - то и получается столетий. И эта объектная модель узко-специализирована для решение учетных задач.
Зачем ей универсальность? Ведь мы же помним, что все универсальное хуже чем специальное?
Теперь о способе подключения сторонних наработок.
Оставим за бортом устаревшие OLE и AciveX. На текущий момент 1С позволяет:
подключить стороннюю библиотеку DLL
вызвать внешний web сервис
реализовать web сервис на своей платформе
Что еще надо? Эти возможности закрывают все возможные потребности. Разве нет?
И вот получается что 1С обладает:
мощной платформой для учетных задач
языком достаточным для программирования учетных задач
развитыми средствами интеграции со сторонними системами.
Добавление сюда стороннего языка (хоть ООП, хоть функционального) никоим образом не улучшает ситуацию ни в одном из пунктов.
И снова в моей голове звучат вопросы: А зачем? Какую задачу мы хотим решить добавление Java в 1С? Кто будет оплачивать человеко-годы новой разработки? Как это объяснить людям, принимающим решение?
PS 1С узкоспециализированная платформа со своим DSL и не надо решать на ней вопросы общесистемного программирования. Незачем на 1С формировать сырые IP пакеты для пингования удаленного сервера.
PS Про разнообразие "Кому на чем нравится, на том пусть и пишет". Есть такой принцип любой промышленной разработки: Лучше безобразно, но единообразно. Разнообразие просто приводит к повышению стоимости сопровождения.
PS к ресурсам компьютера - всегда легко их увеличивать, когда это делается не за твой счет. К тому же есть ограничения физические, например на размер памяти.
Карликовый желтый гигант