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

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

21.04.2021     

Компания 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.
Даже еще до того, как появилось слово "микросервис". :)

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

См. также

Базовые функции Google Workspace стали доступны для бесплатных учетных записей

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

14 июня Google разместила в своем блоге статью с информацией о том, что базовые функции Google Workspace становятся бесплатными.

18.06.2021    1226    capitan    0       

Компьютеры Mac на Intel не получат ряд новых функций macOS Monterey

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

Apple опубликовала пресс-релиз с описанием функций новой ОС – macOS Monterey. Согласно превью, новые отдельные функции будут доступны только для устройств с чипом M1.

17.06.2021    1021    SKravchenko    0       

Инсайдеры раскрыли дизайн Windows 11

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

Компания Microsoft не раз заявляла, что Windows 10 станет последней представительницей семейства. Но в итоге от успешного бренда решили не отказываться. Пришел черед Windows 11. Инсайдеры показали, как она будет выглядеть.

17.06.2021    1378    user1015646    7       

В России начала работу крупнейшая в Европе квантовая магистраль

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

РЖД протестировала и ввела в эксплуатацию вторую по протяженности в мире квантовую магистраль длиной в 700 километров. К 2024 году организация планирует увеличить длительность сети в 10 раз.

16.06.2021    1232    VKuser24342747    1       

Visual Studio Code стал поддерживать работу с удаленными репозиториями без клонирования

Новость GitHub ИТ-новость

Открытая среда разработки Visual Studio Code теперь позволяет работать с удаленными репозиториями GitHub напрямую. Для этого появилось специальное расширение Remote Repositories.

15.06.2021    1579    user1015646    0       

Платформа Yandex.Cloud прошла добровольную аттестацию на соответствие требованиям 152‑ФЗ

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

В апреле 2021 года платформа Yandex.Cloud прошла внешний аудит. Теперь клиенты сервиса могут обрабатывать в облаке любые категории персональных данных, включая биометрические и специальные.

11.06.2021    1315    capitan    1       

Google I/O 2021: главные анонсы конференции для разработчиков

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

Начало лета богато на конференции для разработчиков программного обеспечения. Одно из крупнейших событий международного уровня – Google I/O 2021. В этом году оно прошло в онлайн-формате и принесло больше анонсов, чем обычно.

11.06.2021    1576    user1015646    0       

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

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

«Яндекс» представил новую версию своего поисковика Y1. В числе прочих изменений – использование машинного обучения для генерации подзаголовков объектных ответов и классификации сниппетов. 

11.06.2021    1383    VKuser24342747    0       

Microsoft выложила сборку OpenJDK в открытый доступ

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

Сборка проекта OpenJDK, подготовленная специалистами Microsoft, теперь доступна всем желающим. Решение с открытым исходным кодом можно загрузить в традиционном формате и в Docker-контейнере.

10.06.2021    1408    user1015646    0       

Составлен список из 10 самых полезных репозиториев GitHub

Новость GitHub ИТ-новость

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

10.06.2021    2146    VKuser24342747    0       

Российские компании совместно с Gigabyte наладят выпуск серверного оборудования

Новость ИТ-новость

«Яндекс», «Ланит», «ВТБ» и Gigabyte договорились о создании завода по выпуску серверов и компонентов на территории России. Фабрика может начать выпускать продукцию уже в 2022 году.

10.06.2021    1276    VKuser24342747    0       

Консорциум Всемирной паутины создал комитет по развитию WebExtensions

Новость Интернет ИТ-новость

Организация Консорциум Всемирной паутины W3C создала WebExtensions Community Group (WECG) для разработки единых стандартов браузерных расширений. В комитет вошли представители крупных ИТ-компаний.

09.06.2021    1059    VKuser24342747    0       

Google разработал сервис для наглядного отслеживания зависимостей проекта

Новость Google ИТ-новость

Инструмент Open Source Insights позволяет визуализировать граф зависимостей для пакетов. Благодаря сервису можно своевременно обнаруживать проблемы с безопасностью модулей.

09.06.2021    1562    VKuser24342747    0       

10 лучших языков программирования в 2021 году по версии InformationWeek

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

Журнал InformationWeek выпустил топ языков программирования, востребованных среди корпоративных ИТ. Рейтинг составлен на основе нескольких источников сбора и анализа данных. В рейтинг InformationWeek попало десять языков программирования.

08.06.2021    1463    SKravchenko    0       

«Яндекс» разрешил пользователям удалять данные о себе

Новость ИТ-новость Яндекс

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

07.06.2021    1732    VKuser24342747    0       

Компания Virtuozzo бесплатно раздает дистрибутив vzLinux на замену CentOS

Новость Linux ИТ-новость

Операционная система может стать полноценной заменой CentOS, который перестанет поддерживаться с конца 2021 года. Разработала ОС компания с российскими корнями.

03.06.2021    3057    VKuser24342747    0       

«Яндекс» предоставит бизнесу доступ к сервису обогащенных ответов

Новость Интернет ИТ-новость Яндекс

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

03.06.2021    2153    VKuser24342747    1       

Google официально выпускает ОС Fuchsia для умных дисплеев Nest Hub

Новость Android Google ИТ-новость Мобильные приложения

Google сообщил, что обновление коснется владельцев первого поколения Nest Hub. Новая ОС Fuchsia заменит существующее программное обеспечение на основе Cast OS.

02.06.2021    1750    SKravchenko    0       

В Amazon Web Services добавили новую систему запуска и управления контейнерами

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

Компания Amazon открыла общий доступ к ECS Anywhere. Это расширение ECS (Elastic Container Service) для управления контейнеризированными приложениями. Оно обеспечивает быстрое развертывание AWS-приложений в любой вычислительной среде.

02.06.2021    1986    user1015646    1       

Microsoft представила релизную версию менеджера пакетов winget

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

В Windows 10 в ближайшем обновлении будет добавлена утилита Windows Package Manager 1.0. Она позволяет управлять пакетами на устройстве, обновлять их и копировать настройки на новый компьютер.

01.06.2021    2989    VKuser24342747    0       

Microsoft добавила в Teams презентации, вебинары и приложения

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

Microsoft открыл бесплатный доступ к вебинарам и презентациям PowerPoint Live в сервисе Teams. Также на ежегодной конференции Build компания рассказала о возможностях создания приложений на базе мессенджера.

31.05.2021    1496    user1015646    0       

Microsoft разработала систему автодополения кода на базе нейросети GPT-3

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

Платформа Microsoft Power Apps получила функцию автоматической генерации кода на языке Power Fx. Пользователю достаточно словами описать команду, и программа выдаст подходящую формулу.

28.05.2021    1696    VKuser24342747    0       

Энтузиаст создал дистрибутив Linux для записи на дискету

Новость Linux ИТ-новость

Польский разработчик Кшиштоф Кристиан Янковски сделал дистрибутив Floppinux, который помещается на 3,5-дюймовую дискету. Современная операционная система работает на любых компьютерах старше 1989 года.

27.05.2021    2067    VKuser24342747    5       

В России создадут госстандарт для ИИ

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

Российские власти предлагают утвердить ГОСТ для разработок в сфере искусственного интеллекта. В Росстандарте уверены: ГОСТы ускорят развитие инноваций и добросовестной конкуренции в сфере ИИ.

27.05.2021    3278    user1015646    5       

Разработчики Sublime Text представили версию приложения 4.0

Новость ИТ-новость

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

27.05.2021    1679    VKuser24342747    0