Да здравствует Logica: Google представил новый язык программирования

Да здравствует Logica: Google представил новый язык программирования

21.04.2021      22652

Компания Google разработала новый язык для логического программирования – Logica. В его основе – наработки запущенного ранее проекта Yedalog и языка Datalog для программирования декларативной логики. 

Замена SQL 

Разработчики Logica Константин Третьяков и Евгений Скворцов отметили: SQL разрабатывался в 1970-е годы и сегодня используется повсеместно – от небольших сайтов до крупных промышленных систем. Но он не безупречен. Например, в SQL выражения для поиска определенных данных в базе могут занимать десятки строк, а абстракции реализованы очень слабо: так, нельзя передать одну функцию в другую, нет импорта и понятия пакетов. В результате код на SQL очень сложно понимать, поддерживать и использовать повторно – из-за этого эффективность разработки падает. 

Предшественником SQL был SEQUEL (Structured English QUEry Language), и изначально запросы старались строить, как обычные предложения английского языка. Но вскоре программисты поняли, насколько это неудобно. Языки логического программирования решают проблемы SQL, используя синтаксис математической логики высказываний – он проще и чище, чем любой естественный язык. 

Logica расширяет классический синтаксис логического программирования, в первую очередь с помощью агрегации. Название Logica расшифровывается как Logic + Aggregation.

Как устроена Logica 

Код Logica компилируется в SQL и запускается в Google BigQuery с экспериментальной поддержкой PostgreSQL и SQLite. Но выражения в нем лаконичнее, чем в чистом SQL, и в отличие от него, в Logica можно многократно использовать механизмы абстракции. 

Также новый язык поддерживает модули и импорт. Его можно запускать из интерактивного ноутбука Python – в такой среде будет проще и быстрее тестировать различные запросы.

SQL оперирует отношениями, которые представляют собой наборы строк. В логическом программировании аналог отношения – это предикат. Хотя предикат – это набор строк, он подразумевает логическое условие, которое описывает строки отношения. 

Разработчики привели примеры простых предикатов:

MagicNumber(x: 2);

MagicNumber(x: 3);

MagicNumber(x: 5).

В такой ситуации условие MagicNumber (x) должно выполняться, когда х точно равен 2, 3 или 5. В SQL нужно было бы трижды пройти по таблице и объединить результаты:

SELECT 2 AS x

UNION ALL

SELECT 3 AS x

UNION ALL

SELECT 5 AS x;

В Logica это выглядит проще:

MagicNumber(x:) :-

 x in [2, 3, 5];

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

Еще один пример – повторное использование кода. Предположим, нам нужно найти в таблице все комментарии от пользователя с id = 5:

MagicComment(comment_text:) :-

 `comments`(user_id:, comment_text:),

 user_id == 5;

А теперь – от пользователей, идентификаторы которых вычисляет предикат MagicNumber: 

MagicComment(comment_text:) :-

 `comments`(user_id:, comment_text:),

 MagicNumber(x: user_id);

Язык позволяет упаковать подобный код в отдельный модуль и импортировать его, как в Python:

import my_project.magic.MagicNumber;

Logica – проект с открытым исходным кодом. Его репозиторий доступен на GitHub. 

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



Источник: https://infostart.ru/journal/news/tekhnologii/da-zdravstvuet-logica-google-predstavil-novyy-yazyk-programmirovaniya_1428711/
Автор:
Ксения Шестакова Обозреватель


Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Darklight 27 21.04.21 17:38 Сейчас в теме
Что-то не понравилось, некрасиво совсем как-то выглядит. Хотя согласен - что язык SQL устарел и нуждается в замене. Идея с предикатами поначалу показалась здравой - но показаны примеры мне показались синтаксически очень кривыми, не шибко лучше аналогичных в SQL.
Пример с вычисляемыми предикатами вообще не понял; на самом деле вообще плохо понимаю я эти примеры:
В такой ситуации условие MagicNumber (x) должно выполняться, когда х точно равен 2, 3 или 5

Я это трактую как инструкцию логических языков типа Пролога, т.е. мы из источника данных связанного с именем MagicNumber (как связывается - это вообще отдельный вопрос сейчас не буду разбираться) должны выбрать данные, где поле x=2 или 3 или 5 - но тогда это такой запрос SQL
SEL ECT
*
FR OM MagicNumber  
WHERE X in (1,2,5)


А на языке предикатов это как раз могло бы выглядеть так
MagicNumber(x: 2)
MagicNumber(x: 3)
MagicNumber(x: 5)


или проще
MagicNumber(x: [2,3,5])-> далее обработка


А уже в теле предиката можно было бы размещать новые предикаты фильтрации/обработки отобранных данных

Но если нужно генерировать данные как

SELECT 2 AS x
INTO #MagicNumber

UNI ON ALL

SELECT 3

UNION ALL

SEL ECT 5;
Показать


То на предикатах это может быть так

MagicNumber(x) <- x=[1,3,5]
MagicNumber(x)


То есть определили один генератор через другой

для более сложных случаев можно и циклы сделать
MagicNumber(x) <- FOR i  IN [1,3,5] -> x=i;
MagicNumber(x)


Ну или наоборот короче
MagicNumber(x) <- [1,3,5]
MagicNumber(x)


Но всё это примеры слишком далёкие от реальных при работе с базами данных

P.S.
Пояснение
Такая запись
MagicNumber(x,y,z) <-
определяет предикат с полями x,y,z - определение может быть одиночным или возвращать набор данных
Может быть несколько определений предиката - все они будут объединяться (объединять данные) в рамках области определения
MagicNumber(x,y,z="bla-bla-bla") <-
Задаёт полю значение по умолчанию
Такая запись
MagicNumber(x,y,z) ->
делает выборку из уже определённого предиката и справа может быть алгоритм обработки этой выборки
А это
MagicNumber(x,y,z)
То же самое но без обработки
Такая запись
MagicNumber(x,y,z:"bla-bla-bla") ->
Накладывает просто фильтр на поле z
Фильтры могут быть и более сложными
MagicNumber(x:{IF it > 0},y:([1..10]|[-10..-1])&(it % 2 = 0),z:["bla-bla-bla","foo-foo-foo"]) ->
И они могут быть в теле обработки для комплексно-сложных случаев

Если поле, по которому идёт фильтр нужно не включать вы выборку - его можно экранировать, каким-нибудь доп. символом, наример так
MagicNumber(x,y,^z:"bla-bla-bla") ->

Последовательный вызов нескольких предикатов (как в примере в начале) делает выборку из них всех с объединением
Вот такая вот мне ЛОГИКА приходит в голову за 15 мнут размышления

P.P.S.
Пробелы по среди слов в блоках кода - это не я - это движок инфостарта слова корёжит
2. booksfill 21.04.21 18:06 Сейчас в теме
Т.е. предлагается очередная надстройка над SQL, которая сама будет решать как и что писать/читать в реальный SQL запрос?

Если да, то спасибо, но не надо.
Перестали убеждать заклинания: "да, не оптимально, но докупите еще n гигов памяти, процессорных мощностей и все залетает",
"теперь даже кухарка смогёт" .

Всегда надо думать, что оптимальней - закидать шапками или включить голову. Шапки, кажется, кончаются, начинаются метания.

Вот если бы они сделали полноценный язык работы с СУБД, полностью и полноценно заменяющий SQL, поддерживающийся ведущими вендорами СУБД , как основной, и имеющий единый стандарт- другой разговор.
Vyacheslide; +1 Ответить
3. Darklight 27 22.04.21 10:05 Сейчас в теме
(2)
Вот если бы они сделали полноценный язык работы с СУБД, полностью и полноценно заменяющий SQL, поддерживающийся ведущими вендорами СУБД , как основной, и имеющий единый стандарт- другой разговор.

Думаю, что без прохождения пути надстройки над SQL, ни один новый язык выборки данных никогда не заменит SQL на уровне СУБД.
Так же замечу, что вероятно язык разрабатывался не только как замена SQL - но и как обобщённая альтернатива для NoSQL СУБД.
Как разу Google есть своя NoSQL СУБД BigTable
Относительно недавно Google представила и NewSQL реляционно-нереляционную СУБД (наверно что-то типа SAP HANA, только с корнями из NoSQL архитектуры) Cloud Spanner - сейчас там язык SQL-подобный, но, вероятно, язык Logica туда будет со временем встроен на уровне самой СУБД, без промежуточной трансляции в SQL

Но, я не вижу особых проблем и с авто трансляцией в SQL - почему считаете что это априори неэффективно? Всё зависит от движка трансляции: насколько хорошо он умеет оптимизировать запросы, в т.ч. опираясь на статистику из СУБД и на статистику прошлых выполнений - тут преимущество именно в динамичности таких запросов - нет жёстких SQL продукций - каждый раз транслятор один и тот же запрос может изменить или взять из кеша уже готовый. Да, язык SQL не очень располагает к удобной оптимизации, да - у его на различных диалектах разных СУБД есть полно нюансов оптимизации. Отчасти транслятор мог бы и сам пользоваться этими нюансами оптимизации (если не на коленке написан; в т.ч. получая специальные метауказания-подсказки от программиста), отчасти просто забивая - бес серьёзной потери в производительности. Считаю, что не для OLTP решений трансляция в SQL не имеет серьёзных камней производительности. А в OLTP для не шибко сложных запросов (а обычно так и есть) тоже вполне себе справится. Более того, ещё и сгладит ошибки и нептиммальности составления запросов - так что в среднем будет куда более эффективно выполняться, чем если все будут писать на SQL не тратя сутки на пролёт времени высококвалифицированных SQL программистов на оптимизацию каждого запроса (и потом ещё не меньше времени на периодический анализ и переделку запросов по факту их выполнения и изменения состояния данных или нагрузки в СУБД).
Вот - язык запросов 1С - это же тоже трансляция в язык SQL диалекта конкретной СУБД - да тут транслятор слабоват - да тут мало возможностей по специальной оптимизации на уровне исходного транслируемого языка. Но работает. Нет... ну скажете, что плохо работает - и я соглашусь - просто так сделано - плохо! Можно было куда лучше сделать! Но 20 лет назад - это было вполне неплохо. А ещё через 20 лет, в будущем поколении 1С Предприятие - конечно, нужно сделать куда более продвинутый транслятор (видимо с AI анализатором в комплекте).

Вон SAP HANA - да - там свой язык и своя поддержка на уровне СУБД - работает хорошо - возможно и компания1С со временем пойдёт таким путём - хотя делать свою производительную СУБД вряд ли по зубам компании 1С - это вообще мало кому по зубам - но поживём, увидим, вероятно, если будут делать свою СУБД, то в партнёрстве с именитыми компаниями - хоть с той же Postgres Professional. Но отказываться от поддержки MS SQL Server и Oracle СУБД - было бы самоубийство - поэтому для своей СУБД могу сделать прямую поддержу своей системы запросов, а для других - как сейчас - трансляцию в SQL (главное лучше, чем сейчас - но этот опыт "набьют" при создании своей СУБД)
4. booksfill 22.04.21 17:48 Сейчас в теме
(3)
Но, я не вижу особых проблем и с авто трансляцией в SQL - почему считаете что это априори неэффективно?


Все просто: если Logica = эффективности SQL + кардинально упрощает жизнь, то нет никакой необходимости в промежуточном SQL. И ваш же пример с "SAP HANA" это подтверждает.
А если Logica рождает нечто "нормальное в 80%" случаев, то уже в 99% случаев будут докупать железо и/или терпеть тормоза.

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

Я вовсе не сторонник "копания в ассемблере" - все, чего хочется, так это того, чтобы любая надстройка,
не важно как ее назвать Hibernate, Logica, давала те же возможности, что дает сейчас SQL + облегчала жизнь.
И не вижу причин почему этого нельзя сделать абстрагируясь от вида СУБД.

P.S.
И по поводу 1С - я, возможно ошибочно, понимаю язык запросов 1С как обычный ORM, но мне непонятно, почему его практически не развивают, хотя бы в самых насущных аспектах. Не думаю, что в 1С не понимают, что без секционирования, возможности нормальной работы с индексами и т.д и т.п., работать с большими системами печально уже сейчас.
Возможно можно надеяться, что готовится что-то серьезное.
5. Darklight 27 23.04.21 10:59 Сейчас в теме
(4)
Logica = эффективности SQL + кардинально упрощает жизнь, то нет никакой необходимости в промежуточном SQL

Как Вы не понимаете, промежуточный SQL нужен не для эффективности - а для совместимости. Сейчас практически все реляционные СУЬД базируются на SQL языке обработке данных (да ещё и наплодили кучу проприетарных диалектов). И ни один новый язык не сможет раз - и потеснить прижившийся за десятилетия язык SQL. Вот, даже, NoSQL СУБД, которые принципиально абстрагировались от ущербного SQL (зачастую заменяя его не менее ущербными прориетраными многочисленными реализациями новых языков) - сейчас снова возвращаются к SQL (пусть и к некоему подобию) - взять хоть Yandex ClickHouse или уже упомянутый Google Cloud Spanner. И делают они это не из-за любви к SQL.
А потому, что программисты к нему привыкли - сейчас SQL - это де-факто универсальный стандарт обработки данных. Поддерживаемый, очень большим числом СУБД, включая некоторые NoSQL.
И вытеснить SQL даже за десятилетия - это непосильная уже задача.

SAP HANA - это всё-таки несколько иное - в SAP R3 вообще прямые SQL запросы как-таковые отсутствуют (там что-то такое же как в 1С - но внутри да - есть свой унитарный механизм запросов SAP - которые транслируются в запросы СУБД).
В SAP HANA эту идею развили глубже - так как теперь там и СУБД стала проприетарная. Вот как раз в этом случае да - можно и не поддерживать SQL - а сразу везде поддерживать исключительно новый язык напрямую - т.к. и СУБД уже для этого разработана (и другой быть не может) и программисты изначально уже приучены к отсутствию прямой поддержки SQL.

Если бы компания 1С для 1С Предприятие 9 разрабатывала свою проприетарную СУБД - то да, можно было бы сразу внутри делать свой проприетарный (ну или взять какой-то иной - ту же LOGICA) язык запросов - чтобы уйти от морально устаревшего SQL. Но как бы хуже не вышло:
Вон, в 1С 7 - был язык проприетарный запросов - от которого все плевались - и да - он был плох, но это не значит, что его нельзя было доработать до более эффективного и удобного использования, оставив базовый синтаксис
Вон, в 1С 8 - переделали на SQL-подобный язык но тоже, в общем-то, проприетарный и транслируемый - поначалу народу понравилось, но потом, опять стали плеваться - но это, скорей, потому, что язык запросов в 1С Предприятие 8 почти не развивался (и если и развивался - то очень сдержанно под давлением общественности и иных обстоятельств) - за это время диалекты SQL в других СУБД сделали большие рывки вперёд - вообще много чего появилось в СУБД за 20 лет существования платформы 8 (от ранних бета и альфа версий) - впрочем тут и язык разработки программного кода тоже не шибко эволюционировал. Но главное - за это время все недостатки ущербной простой модели языка запросов 1С стала очевидна почти всем.
Добавлю, что уже говорил, даже если компания 1С выкати для 1С Предприятие 9 свою собственную проприетарную СУБД - она вряд ли сможет отказаться от поддержки нынешних основных СУБД - т.к. превзойти их разом компания 1С не сможет даже с партнёрами (ну разве что выйти на уровень PostgreSQL, просто взяв её ядро за основу), да и куплены они уже у многих клиентов - переходный период должен быть плавным. Это не компания SAP с её колоссальными возможностями (да и у той - переход c SAP R3 к SAP HANA не завершён до сих пор - обе системы существуют параллельно).


Лично мне, более симпатизирует модель обработки данных SAP HANA - на её основе я бы предложил язык и для 1С Предприятие 9 (идей много) - главная суть - вообще отказаться от языка запросов - перейти к пакетной объектной модели - через классы объектов заполняются требования к выборке и обработке данных - затем они оптимизируются и отбавляются в СУБД на выполнение (для поддержки классических СУБД - происходит трансляция в пакетный SQL запрос). А на СУБД тоже больше возможностей по обработке - начиная от возможности размещения там хранимых процедур - но это уже прошлый век. Сейчас же рулят микросервисы - в т.ч. выполняемые прямо в СУБД, наспанные на специализированных языках, поддерживаемых этими СУБД - вот эти размещённые в СУБД алгоритмы и должны производить сложные действия по обработке данных. Те самым исходные запросы-требования в большинстве случаев должны быть достаточно алгоритмически-простыми. Так же на микросервисы должна быть вынесена большая часть алгоритмов контроля, мониторинга и конвертации данных - чтобы платформе бизнес приложения об этом не приходилось думать. Вот как писать эти микросервисы - это уже отдельная задача. У SAP HANA это JavaScript - а 1С умеет транслировать свой код в JavaScript - это просто намёк на то, что писать микросервисы можно в основном привычном синтаксисе языка разработки - а далее - он мог бы, транслироваться в поддерживаемые языки целевой СУБД (например у MS SQL Server - это "язык IL" - т.е. байт-код платформы .NET) - но у разных СУБД могут быть разные не то что языки - разные возможности этих языков и разные библиотеки - это самая большая проблема - так что писать микросвервисы, видимо нужно индивидуально для каждой СУБД. Ну, а в платформе 1С уже должно быть встроено множество микросервисов и их количество постепенно должно расширяться.
Вот в такой модели, в общем-то, и языка запросов то уже нет - с клиента идут обектные, скорее декларативные описания требований, а на СУБД идёт вызов микросервисов на специальных языках).
Это не только мой мнение - некоторые другие эксперты уже тоже прогнозирут именно такое будущее развития программирования в СУБД.
И Google LOGICA тут, видимо, тоже готовится к тому пути развития. Но пока - ему без трансляции в SQL никак не обойтись - но это переходный период.

во что 1С превращает "простой" запрос, скажем к регистратору составного типа. И появляются великие откровения типа использования "Выразить".

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

а. Это недостаток синтаксиса языка - позволяющий просто написать неоптимальный код, и сложно оптимальный - тут можно поработать над синтаксисом - чтобы выставить баланс на двух чашах весов. В частности синтаксис "ВЫРАЗИТЬ" просто очень неудобен в использовании. А прямое обращение через точку - наоборот удобно. С последним пока я не знаю как сделать так, чтобы усложнить жизнь, не превратить её в ад. А с первым да хотя бы такой синтаксис как
"ВЫРАЗИТЬ(Регистратор КАК Документ.{ПриходныйКассовыйОрдер, РасходныйКассовыйОрдер, ПлатежноеПоручениеИсходящее, ПлатежноеПоручениеВходящее}).СчетРассчетов"
уже сильно упростило бы жизнь. А если виды метаданных можно было бы объединять в группы - так вообще круто было бы
"ВЫРАЗИТЬ(Регистратор КАК ГруппаПлатежныхДокументов}).СчетРассчетов".
А ещё круче - это поддержка интерфейсов, и с ещё более простым синтаксисом
Регистратор:ПоддержкаРасчетов.СчетРассчетов.
Иным подходом могли бы стать объекты как "View" (или хранимые процедуры) - ну суть та же - заранее ограничить набор возможных типов составного типа в источнике.

б. Это недостаток отсутствия встроенного анализатора возможных ошибок - IDE нового поколения должны больше следить за кодом программиста и выявлять проблемные места и сигнализировать о них. Как сразу. Так и потом - автоматически собрав планы выполнения проблемных алгоритмов и выкатив их в отчёте с предложениями по их улучшению.
Кстати, описанные в пункте а. подходы к решению проблемы хороши и для системы анализа - просто платформа проводя постоянный мониторинг выполнения запросов и выявляла бы и желаемые индексы, и желаемые группы, и желаемые приведения к сокращённым составным типам и т.п. – и информировала об этом программиста (по и идеи даже не программиста, а специалиста по техническим вопросам и оптимизации клиент-серверного взаимодействия – а он уже передавал бы задачи программистам на конкретные доработки, ну или выполнял бы их сам).

Ну а, что касаемо составных типов - особенно документов - особенно регистратора - вот тут как раз всякие "ВЫРАЗИТЬ" не часто является подходящим решением - т.к. нужна обработка всех документов, в т.ч., возможно, появляющихся позже. Вот поэтому выше я и предложил более удачны решения - где фильтрация выносится за пределы запроса - и является задачей общей архитекторы.
А если система запроса и обработки данных становится более декларативной – то ту вообще возможностей по анализу, совмещённому с постоянной оптимизацией, в руках платформы очень много – в идеале – она сама могла бы выявлять узкие места и устранять их (не все, но хотя бы часть).

Я вовсе не сторонник "копания в ассемблере" - все, чего хочется, так это того, чтобы любая надстройка,
не важно, как ее назвать Hibernate, Logica, давала те же возможности, что дает сейчас SQL + облегчала жизнь.
И не вижу причин почему этого нельзя сделать абстрагируясь от вида СУБД.

Я понимаю Ваше желание, но понимаю, что это практически невозможно - потому что это как раз сродни возврату к уровню ассемблерного программирования с необходимостью поддерживать диалекты разных платформ выполнения, да ещё и в постоянно меняющейся архитектуре этих платформ. Это уже пройденный этап – развитие так идти не будет (хотя, вот в вебе наоборот – набирает популярность Web Assembler – но это особый случай, и он клиентский, а не серверный). Основное программирование сейчас движется в сторону управляемых приложений (когда их выполнением управляет внешняя платформа) – где за счёт жертвы производительности (небольшой жертвы – т.к. средства оптимизации постоянно улучшаются, а накладные расходы сокращаются) ускоряется процесс программирование и минимизируются ошибки. Всё это итоге снижает издержки бизнеса и повышает масштабирование. Так что да – зачастую проще и дешевле вложиться в апгрейд железа – чем постоянно вкладываться в исправлении ошибок, оптимизацию и перестройку программного кода. Тем более с тенденцией к переходу на программирование параллельной обработки данных – код становится сложнее, его оптимизация и устранение ошибок тоже – а вот масштабирование параллельного кода – наоборот становится дешевле.

С вашим постскриптумом я полностью согласен. Подозревая, что развитее отсутствует в угоду упрощения программирования - такова была политика Бориса Нуралиева ещё со времён 1С 7 и активно позиционировалась вместе с 1С Предприятие 8 – программировать на этой платформе должно быть так легко – чтобы справился даже бухгалтер (как он и справлялся ещё в Бухгалтерии 5 и на 1С Предприятие 6) – но это, так и осталось иллюзией. А сейчас наоборот БСП и типовые конфигурации стали очень сложны в сопровождении и оптимизации именно из-за ущербности языков и устаревших концепциях архитектуры программного кода. Но что-то принципиально менять – это революция (эволюцией уже не обойтись) – а этого Борис боится больше всего (как и большинство людей пред пенсионного возраста) – и его понять можно – переходы 1С 7 -> 1С 8 и 1С 8.1(2) -> 8.3 TAXI (и даже ПРОФ -> КОРП) были очень болезненными и для сообщества, и для компании 1С – поэтому то, до сих пор и нет ранее анонсированный (ныне забытой) 1С 8.4. Поэтому – если и будет революция – то уже в 1С Предприятие 9 – лет так через 20, когда старые управленцы в 1С уйдут на пенсию – а конкуренты уже будут совсем на другом уровне технологий! А пока 1С в России и так хорошо продаётся. А на запад (как и на восток) в нынешнем виде и обстановки выйти никак не удаётся. Значит берегут силы и финансы для нового крупного рывка. Ну или просто сольют подразделение компании – когда платформа устареет настолько, что большинство потребителей будут предпочитать конкурентов (коих в России то и нет почти), а до этого момента будут создавать видимость плавного консервативного развития – ведь в стане 1С сообщества не мало таких же консерваторов, считающих, что 1С Платформа 8 может и не идеальна – но ведь уже почти 20 лет хорошо работает, так и трогать её не нужно, а кто жалуется – просто «не умеет её готовить»!
6. booksfill 23.04.21 16:00 Сейчас в теме
Да, согласен я с тем, что "приходится в SQL" (просто написал, чего хотелось бы видеть в идеале).
Но абстракция, построенная на нижележащей, должна давать минусов меньше, чем плюсов.
Мне кажется, что этот язык (вообще-то напоминающий набор обычных шаблонов)
минусов дает больше. Хотя бы потому, что не освобождает от изучения SQL, требует затрат времени на свое изучение, и провоцирует на написание потенциально неэффективного кода.

Что касается микросервисов я в этом очень плохо разбираюсь.

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

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

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

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

P.S.
Значит берегут силы и финансы для нового крупного рывка

Хотелось бы надеяться, но 1С понял это еще лет 15 назад и тайком что-то плодит, но верится с трудом.
Иначе где инсайд?
7. Darklight 27 27.04.21 12:11 Сейчас в теме
(6)
просто написал, чего хотелось бы видеть в идеале

Да по сути, Вы ничего не написали - ваше желание сравнимо с утверждение - "только SQL - только хардкор" - т.е. Вы хотите SQL, но, с одной стороны не вроде бы не против его расширения, с другой - против расширения для упрощения синтаксиса в ущерб эффективности (против синтаксического "сахара", который в неумелых руках может снижать эффективность)!
Но я Вам скажу - даже ANSI SQL в неумелых руках легко позволяет писать крайне неэффективные алгоритмы - а уметь писать на нём сложные эффективные алгоритмы - это искусство для настоящих мастеров! Коими большинство программистов баз данных совсем не является!
Чего только стоит то, что нужно правильно соблюдать порядок полей в условиях - чтобы применились индексы. Да - это старая проблема - да - некоторые СУБД её умеют сами оптимизировать. Но... IBM DM2 не умеет, PosgtreSQL не умеет. И 1С Предприятие 8 это знает - поэтому сама правильно переставляет условие при трансляции своих запросов в SQL.
Но это я привёл самый простой пример - а таких в SQL ещё тьма! Взять хотя бы оператор "IN" для небольших дискретных выборок - большинство СУБД так же не умеют его оптимизировать в набор нескольких условии на равенство (и 1С Предприятие 8 тоже) - а для них это чаще эффективнее (когда есть индексы), чем формирование отдельной временной таблицы с этими значениями. И многие ли программисты будут оптимизировать "ГДЕ Код В (1,2,3,4,5)" превращая его "ГДЕ (Код = 1 ИЛИ Код = 2 ИЛИ Код = 3 ИЛИ Код = 4 ИЛИ Код = 5)" (не все СУБД это умеют оптимизировать, а 1С в любом случае сделает временную таблицу). Это я не говорю о том, что зачастую (при наличии индексов) - запрос будет ещё быстрее - если его разбить на несколько объединений - писать руками - это просто кошмар!


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

Конечно плюсов должно быть больше. Но полностью исключить минусы вряд ли удастся. Да и минусы и плюсы - имеют разный вес в зависимости от области применения таких абстракций. Где легче и быстрее писать код с меньшим числом ошибок (и какой код будет понятнее), на С++, Rust, С, C#, Python, 1C? Каждому языку - своя область применения.
Про минусы LOGICA пока сложно судить - с ней нужно лучше разобраться. Но пока я не смог оценить даже её плюсы. Но... это не значит, что идею нельзя довести до ума - минимизировав минусы, добавив плюсов.

Что касается микросервисов я в этом очень плохо разбираюсь

Микросевисы 1С-нику проще воспринимать как удалённые процедуры сервера, вызываемые с клиента (даже без всяких там web/http сервисов, хотя можно ещё REST API упомянуть - но это будет слишком простой микросервис). Смысл микросервиса - Вы вызываете с некими параметрами для (возможно) некоторых данных - он их обрабатывает - и возвращает ответ (возможно результат). Микросервисы в СУБД в простейшем виде - это хранимые процедуры. Отчасти микросервисами (но не фактически) можно считать виртуальные таблицы 1С. Реально - сейчас в ряде СУБД можно писать вообще свой код обработки данных (например для MS SQL Server можно писать алгоритмы на платформе .NET) - а потом обращаться к ним прямо из SQL синтаксиса - как к функциям (например, можно написать свою агрегатную функцию) или как источникам данных (с параметрами, как хранимые процедуры, но с большими возможностями). Если будет стандартная библиотека работы с бизнес-сущностями 1С ИБ - то можно писать очень интересные микросервисы обработки таблиц прямо в СУБД - вот об этом и речь. В идеале - можно вне микросервисов вообще отказаться от SQL запросов - перейдя на декларативный подход к выборке (и изменению) данных - вызывая такие алгоритмы прямо на СУБД - передавая им декларативные настройки этих выборок. А возможности микросервисов на СУБД куда шире, чем возможности клиентов СУБД. А если чего-то будет не хватать - просто пишете свой микросервис - и используете его с клиента (или с сервера приложений).

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

Хотелось бы надеяться, но 1С понял это еще лет 15 назад и тайком что-то плодит, но верится с трудом.

15 лет назад 1С ещё только только перешла на кластерную архитектуру и работала над управляемым приложением. То есть развивала ещё совсем молодую 8-ку. Но в последние лет 5 они занимаются развитием мобильного приложения и думают как раз о микросервисной архитектуре (таковой доложена была быть платформа 8.4 но её отменили). Так что микросервисы припасены для более серьёзного революционного перехода, которого боятся на верхах компании 1С. Пока 1С Предприятие 8 развивается медленно и эволюционно. Никаких анонсов о разработке принципиально новой платформы нет. Видимо ещё не время. Поэтому я прогнозирую революцию не ранее 2040 года - да и то, возможно к тому сроку только официальный анонс сделают, а на разработку финального коммерческого релиза уйдёт ещё лет 10-15. Но это не значит, что в компании 1С не ведут теоретическое проектирование того, что хотелось бы создать в будущем. Нет смысла выкатывать сейчас что-то похожее на 1С Предприятие 8 - выдавая за совершенно новый продукт, который срочно всем надо купить.1С Предприятие 9 - должна стать принципиально новой платформой, а не развитием 8-ки. И должна быть заметно более привлекательной - чтобы её захотели купить не единицы, а миллионы потребителей
8. booksfill 27.04.21 18:22 Сейчас в теме
Спасибо про разъяснения по микросервисам, я правильно понял, что одним словом назвали множество сильно разных технологий c "Общим подходом к API" ?

"Честное слово, я и не подозревал, что вот уже более сорока лет говорю прозой." (С. Жан Батист Мольер).
Оказывается, я уже много лет использую микросервисы, причем даже на "высоком идейном уровне",
т.к. делал работу офиса на 120 менеджеров с облачной телефонией, как раз на основе REST API.
Даже еще до того, как появилось слово "микросервис". :)

Что касается "это уже отдельные (условно) автономные сервисы", я плохо понимаю, когда их имеет смысл использовать. Кажется, исходя из тех проблем, о, которых я писал ранее - проглядывают уровни очень больших компаний. Нет, использовать могут и небольшие фирмы, но минусов, по-моему, они получат куда больше. Ибо затраты будут несопоставимы с полученным эффектом.
Оставьте свое сообщение

См. также

Российская ОС «Аврора» получила крупное обновление до версии 4.0

Новость ОС ИТ-новость Мобильные приложения Новости компаний

Компания «Открытая мобильная платформа» выпустила мобильную операционную систему «Аврора» 4.0. Релиз включает более 300 улучшений, из них 40 – важные нововведения.

03.12.2021    7503    VKuser24342747    2       

Российские банки запустили систему переводов без номера телефона и карты

Новость Банки Безопасность ИТ-новость

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

02.12.2021    5372    VKuser24342747    3       

Сотрудники Минцифры протестируют сервисы VK для госслужащих

Новость ИТ-новость Минкомсвязь Цифровая экономика

Компания VK разработала набор приложений для автоматизации работы госслужащих. Первыми получат возможность опробовать мессенджер, файлообменник, почту и другие сервисы чиновники из Минцифры.

02.12.2021    6855    VKuser24342747    0       

Лаборатория Касперского представила бесплатную ОС

Новость ОС Безопасность ИТ-новость Новости компаний

«Лаборатория Касперского» выпустила собственную операционную систему. На базе KasperskyOS можно создать решения, которые защищены от многих видов кибератак.

01.12.2021    6212    user1015646    2       

«Яндекс» представил сервис для сканирования документов

Новость ИТ-новость Новости компаний Яндекс

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

01.12.2021    7104    VKuser24342747    1       

OpenAI открывает доступ к API GPT-3

Новость Искусственный интеллект ИТ-новость Новости компаний

Компания OpenAI предоставила доступ к API (прикладному программному интерфейсу) алгоритмов обработки естественного языка GPT-3. Это открывает новые возможности для экспериментов с умными системами, которые могут имитировать человеческие возможности – например, писать стихи или отвечать на вопросы.

29.11.2021    5292    user1015646    0       

Компания JetBrains представила легковесный редактор Fleet

Новость ИТ-новость Новости компаний

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

29.11.2021    5550    ЕленаЧерепнева    8       

Разработчики Astra Linux создали аналог Microsoft Active Directory

Новость Linux Безопасность Импортозамещение ИТ-новость Новости компаний

Группа компаний «Астра» представила службу ALD Pro, которая замещает в российской ОС Astra Linux решение Microsoft Active Directory. Поддержку этой функции от системы часто требуют госзаказчики.

29.11.2021    8359    VKuser24342747    1       

Специальный алгоритм очистит данные переписи населения

Новость Искусственный интеллект ИТ-новость

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

26.11.2021    7106    VKuser24342747    0       

В офисах Google появились универсальные роботы

Новость Автоматизация ИТ-новость Новости компаний

Офисы Google в Маунтин Вью, штат Калифорния, теперь станут гораздо чище. К уборке привлекли универсальных роботов, разработанных X Company, которая, как и поисковый гигант, входит в состав холдинга Alphabet.

25.11.2021    6491    user1015646    2       

Вышло крупное обновление для TypeScript с автодополнением кода

Новость ИТ-новость Языки программирования

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

24.11.2021    10624    VKuser24342747    4       

GitHub назвал три ключевых тренда в разработке за 2021 год

Новость GitHub Аналитика ИТ-новость

GitHub провел традиционное ежегодное исследование Octoverse, чтобы определить основные направления развития ИТ-индустрии. В 2021 году актуальными стали вопросы быстрого написания кода и подготовки документации.

24.11.2021    11088    VKuser24342747    0       

Рособрнадзор прекратит использовать Windows при проведении ЕГЭ

Новость Импортозамещение ИТ-новость

Единый государственный экзамен к концу 2024 года будет проходить без использования ОС Windows во всех местах, где можно сдать тестирование. Вместо нее будет установлена российская система.

23.11.2021    7265    VKuser24342747    5       

Google выпустил версию браузера Chrome 96

Новость Интернет ИТ-новость Новости компаний

Новая актуальная версия Google Chrome 96 получила расширение инструментов для веб-разработчиков и экспериментальные функции в мобильной версии.

23.11.2021    7506    VKuser24342747    1       

Через Госуслуги компании подтвердили 13,3 млн корпоративных SIM-карт

Новость Безопасность ИТ-новость Телекоммуникации

Министерство цифрового развития сообщило, что компании соблюдают новые требования закона «О связи» и уже зарегистрировали на портале госуслуг 13,3 млн рабочих SIM-карт.

22.11.2021    8608    VKuser24342747    1       

Visual Studio 2022 и .NET 6: что нового

Новость ИТ-новость Новости компаний Языки программирования

Microsoft выпустила свежий релиз одной из самых популярных сред разработки. Вместе с Visual Studio 2022 представили обновленную платформу .NET 6.

22.11.2021    10641    user1015646    0       

Программист разработал поисковую систему без слежки за пользователями

Новость Безопасность Интернет ИТ-новость

Бывший разработчик из компании Salesforce Ричард Сокер открыл публичный доступ к своему поисковому сервису You. В нем нет никаких трекеров личных данных и рекламных материалов.

18.11.2021    7020    VKuser24342747    3       

«Сбер» обучил нейросеть ruGPT-3 генерировать программный код

Новость Искусственный интеллект ИТ-новость Новости компаний

Новая функция самой большой генеративной AI-модели для русского языка получила название JARVIS. Сейчас сервис способен работать с языками программирования Java, Python и JavaScript.

18.11.2021    6862    VKuser24342747    2       

Университет Иннополис создал уникальный российский индустриальный блокчейн

Новость Блокчейн ИТ-новость

В России разработан блокчейн InnoChain, который предназначен для использования в закрытых сетях. С его помощью можно подписывать договоры и планировать объемы продаж.

17.11.2021    7584    VKuser24342747    0       

В Dropbox появились «автоматизированные папки» и новая система тегов

Новость ИТ-новость Облачные технологии

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

17.11.2021    7206    SKravchenko    1       

Microsoft выпустит платформу Defender for Business

Новость ИТ-новость Новости компаний

Microsoft Defender for Business станет частью комплексного решения Microsoft 365 Business Premium, которое объединяет Microsoft Teams и Office 365 с основными инструментами безопасности для малого и среднего бизнеса.

16.11.2021    4875    SKravchenko    0       

Adobe Photoshop и Illustrator стали доступны онлайн

Новость

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

11.11.2021    6107    user1015646    0       

Что нового в SQL Server 2022

Новость СУБД MS SQL ИТ-новость Новости компаний

Microsoft на ежегодной конференции Microsoft Ignite анонсировала предварительную версию SQL Server 2022 – теперь СУБД включает интеграцию с базой Azure SQL, службой аналитики Azure Synapse Analytics и платформой управления данными Azure Purview.

11.11.2021    11471    SKravchenko    0       

«Сбер» представил нейросеть для генерации картинок по описанию

Новость Искусственный интеллект ИТ-новость

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

11.11.2021    7329    VKuser24342747    11       

Правительство собирается определить главный российский процессор

Новость Импортозамещение ИТ-новость

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

10.11.2021    6930    VKuser24342747    4