Зачем придумывают всё новые языки-велосипеды?

если сравнивать формошлёпство куте и 1с, то в 1с оно круче и в том числе позволяет работать с БД вообще не написав ни строчки SQL запросы в ручную

И даже не нарисовав собственно форму. Хотя в C++ любой ORM тоже умеет. Но вот если в 1С 7.7 всё было через ORM, то в 1C 8.x всё переписали на русский SQL, только привязка форм к объектам БД осталась безальтернативно через ORM.

Тогда мы с вами разговариваем на китайском языке. Русифицированном.

То есть достижения 1С в пользу SQL засчитывать не хочешь. Ладно, вот SAP: https://developers.sap.com/tutorials/abap-display-data-queries.html

ну и где истории успеха? где там указана статистика использования?

Тебе надо, ты и ищи. Вокруг меня используется достаточно часто. Точнее, всегда, когда надо какой-то анализ данных из Excel сделать. Можно, конечно, и на Visual Basic'е написать, но запрос-то быстрее.

Всё, что после «Запрос.Текст =». Русифицированный.

Тогда мы с вами разговариваем на китайском языке. Русифицированном.

Там полностью совпадающий синтаксис и семантика с SQL. Только киррилица вместо латиницы.

У русского и китайского тоже только слова разные. И это реально имеет значение. Американец, например, вышеприведённый код не поймёт. Даже если он (американец) знает SQL.

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

Ну то есть: «Я был ходить сказать была не справедливая аналогия».

С английского же получается. Например, «я есть инженер». Или «я имею сделанную работу». Звучит коряво, но вполне понятно. Проблемы как раз начинаются из-за множественного значения слов, которые зависят от контекста. Например «case» - можно перевести и как случай и как чемодан. Но если сами слова перевести правильно, всё вполне становится понятно.

Да. Так о чем разговор? Язык программирование определяется семантикой и синтаксисом, а не кодировкой символов, в которых он записан (koi8, win1251, utf8).

Вы как-то плавно перешли от сомнительного тезиса «написание sql запросов вручную даёт преимущества на порядок и более по сравнению с любыми другими методами разработки» к «sql используется повсюду для работы с таблицами», в чём никто не сомневается.

Так одно из другого следует. Если бы SQL и регулярные выражения не давали преимуществ для своей предметной области, их бы никто не использовал. Вот для сериализации объектов SQL синтаксических преимуществ не даёт, так его всюду ORM'ами заменяют. Затем иногда переписывают обратно на SQL, так как ORM адски тормозит.

Так одно из другого следует.

нет

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

обоснуйте

Затем иногда переписывают обратно на SQL, так как ORM адски тормозит.

если из базового ЯП исключительно хранимые процедуры вызывать, (необязательно на SQL написанные - там вагон языков), то ORM ни при каких обстоятельствах тормозить не будет

очевидное решение, но ведь слишком простое, поэтому, люди занимаются, как вы правильно заметили, переписыванием туда - обратно

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

1) Безальтернативность (javascript)

2) Некомпетентность (МММ)

3) Индивидуальные пределы возможностей мышления (шахматы)

4) Прямой приказ сверху

если из базового ЯП исключительно хранимые процедуры вызывать, (необязательно на SQL написанные - там вагон языков), то ORM ни при каких обстоятельствах тормозить не будет

Будет. Потому что UPDATE t SET x = x + 1 WHERE y=42 в ORM превращается в загрузку тучи объектов, установку в каждом x=x+1, сохранения объектов обратно.

А запихивать всю логику программы внутрь СУБД — это очень тесно от неё зависеть, потом мигрировать на другую будет почти невозможно.

И что из них, по-твоему, относится к SQL и регуляркам?

Безальтернативность? Очевидно нет. Как работу с таблицей данных, так и разбор строки можно сделать и вручную.

Некомпетентность? За 30 лет не нашлось ни одного компетентного программиста. Есть компетентный next_time, но ему лень написать правильную альтернативу. Как-то неправдоподобно получается.

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

Прямой приказ сверху использовать SQL и регулярки для всех программистов Мира — это теория заговора покруче жидомасонского будет.

UPDATE t SET x = x + 1 WHERE y=42 в ORM

не будет никакого UPDATE t SET в ORM, а будет «perform increment_in_t(42)»

А запихивать всю логику программы внутрь СУБД

запихивать в СУБД нужно ровно ту логику, которую нужно. если нужно всю, значит всю

потом мигрировать на другую будет почти невозможно

и что?

На моем прошлом проекте, 95% бизнес-логики было на стороне БД и ничего, брат жив. Были проекты, где 0% бизнес-логики было на стороне БД, тоже неплохо.

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

разбор таблиц можно в том же экзеле сделать многими способами, а вот в РСУБД отчасти безальтернативен sql

За 30 лет не нашлось ни одного компетентного программиста.

...который захочет сделать NoSQL БД... ой да таких БД немало

Прямой приказ сверху использовать SQL для всех программистов Мира

нет, конкретно на вашем рабочем месте

а вот в РСУБД отчасти безальтернативен sql

Сам же пишешь, что вместо SQL можно сделать хранимку на C++, которая пройдёт по записям таблицы безо всякого SQL.

...который захочет сделать NoSQL БД... ой да таких БД немало

Ага. И сотни тысяч страниц с вопросами наподобие «Как сделать JOIN в MongoDB?». Видимо SQL оказался удобнее. Все аргументы про NoSQL были «Ну да, работать неудобно, но ведь с ним быстрее будет».

Сам же пишешь, что вместо SQL можно сделать хранимку на C++, которая пройдёт по записям таблицы безо всякого SQL

Можно в MS SQL server. В Postgres и Oracle я не знаю, как. Может, тоже можно. Или будет можно.

Все аргументы про NoSQL были «Ну да, работать неудобно, но ведь с ним быстрее будет».

NoSql разный бывает. Есть графовые БД - там наоборот. Возможностей больше, но медленней.

И сотни тысяч страниц с вопросами наподобие «Как сделать JOIN в MongoDB?». Видимо SQL оказался удобнее.

и сотни тысяч страниц с вопросами наподобие «Как выйти из vim». Видимо, gedit оказался удобнее.

Ага. И сотни тысяч страниц с вопросами наподобие «Как сделать JOIN в MongoDB?». Видимо SQL оказался удобнее. Все аргументы про NoSQL были «Ну да, работать неудобно, но ведь с ним быстрее будет».

Во-первых, сама идея монги не подразумевает джоинов. Там иная организация хранилища с независимыми документами.

Во-вторых, для особо капризных джоины уже давно завезли в монгу с 3.2 (4 года назад).

В-третих, я в молодости писал приложения в делфи с локальными базами безо всяких SQL, но со связанными таблицами, и было это убер просто - это наследние FoxPro/dBase/Clipper, которое в свое время доминировало на рынке, где про SQL никто не хотел знать. SQL понадобилось, когда возникла необходимость в клиент-сервере. Но время проходит, и сейчас уже пришла BigData и кластеры, на которых SQL уже не работает - оно предназаначено для работы только в рамках одного сервера. Если ты не согласен с этим утверждением, то предлагаю тебе придумать, как сделать банальный джоин между двумя узлами.

Давайте теперь писать на говне мамонта глючные программы

Словно новые программы безглючные

Не безглючные, но пишутся быстрее. А бизнесу что нужно? Правильно - herak-herak-driven development. Мало кто нынче может позволить тщательнюу и длительную разработку софта. Ну, то есть намного большое появилось заказчиков, которым нужно быстрее и дешевле. Причем, в том числе такие солидные, казалось бы, заказчики, как тот же боинг.

А бизнесу что нужно?

Вынудить всех платить, желательно много и часто, для этого делают новые версии.

Ну, то есть намного большое появилось заказчиков

По-моему, давно уже никого не волнует, что нужно каким-то пользователям.

Вынудить всех платить, желательно много и часто, для этого делают новые версии.

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

По-моему, давно уже никого не волнует, что нужно каким-то пользователям.

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

и сотни тысяч страниц с вопросами наподобие «Как выйти из vim». Видимо, gedit оказался удобнее.

Так с интуитивной точки зрения реально удобнее. А не с интуитивной... интересно, сколько человек пользуются gedit, а сколько gvim.

NoSql разный бывает. Есть графовые БД - там наоборот. Возможностей больше, но медленней.

Графовые бывают и SQL (с функцией match в разделе WHERE) и NoSQL (со своими велосипедами). Опять же, какие выбирают, если производительность не критична?

Во-первых, сама идея монги не подразумевает джоинов. Там иная организация хранилища с независимыми документами.

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

это наследние FoxPro/dBase/Clipper, которое в свое время доминировало на рынке, где про SQL никто не хотел знать. SQL понадобилось, когда возникла необходимость в клиент-сервере

И после этого SQL вытеснил dBase даже без клиент-сервера (SQLite). Несмотря на то, что решения на dBase были гораздо быстрее. У меня на одной и той же организации в 1С 7.7 месяц закрывается 3 секунды, а на 1С 8 (с MS SQL сервером) — около 3 минут. Но на 7.7 никто возвращаться не хочет.

Так с интуитивной точки зрения реально удобнее.

ага и это ещё один пункт - удобство бывает разным, есть ещё и время изучения

А не с интуитивной... интересно, сколько человек пользуются gedit, а сколько vim

vim-ом значительно больше

Опять же, какие выбирают, если производительность не критична?

NoSQL

vim-ом значительно больше

NoSQL

Статистику бы... Ну ладно, будем считать, что ты прав.

https://www.reddit.com/r/vim/comments/5trtbj/and_the_text_editor_of_the_year_is/

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

Какими текстовыми редакторами вы пользуетесь?

вот ещё. в общем, какой опрос ни возьми, вимом пользуется больше народу

И после этого SQL вытеснил dBase

Вы опять подменяете тезис. Вытеснил? Ну может он и удобнее. Но вам-то надо доказать (ибо таково было ваше изначальное утверждение) что он удобнее на порядок.

А для вытеснения всех конкурентов с рынка достаточно быть удобнее на 10%. При прочих равных.

А для вытеснения всех конкурентов с рынка достаточно быть удобнее на 10%. При прочих равных.

Вообще-то на 25%. Чтобы вступить в конкурентную борьбу. А чтобы однозначно победить...

это не на софтварном рынке

Вытеснил? Ну может он и удобнее. Но вам-то надо доказать (ибо таково было ваше изначальное утверждение) что он удобнее на порядок.

Чтобы доказывать «на порядок» нужна измеримость понятия «удобнее». А доказывал я как раз, что нужны те языки, на которых писать удобнее, чем без тех языков. А придумывают, чтобы получился, соответственно, более удобный язык.

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

вы заявили, что «на порядок» - вам и доказывать

//удобность в человеко-часах измеряется - чем быстрее выходит результат, тем удобнее

А придумывают, чтобы получился, соответственно, более удобный язык.

действительно

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

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

вы заявили, что «на порядок» - вам и доказывать

//удобность в человеко-часах измеряется - чем быстрее выходит результат, тем удобнее

10 строк

SELECT t1
GO TOP
c = 0
SCAN FOR !EOF()
  SELECT t2
  LOCATE FOR id=t1.id
  IF !EOF() AND id=t1.id
     c = c + 1
  ENDIF 
ENDSCAN

Против одной

SELECT count(*) FROM t1 JOIN t2 ON t1.id=t2.id

При том, что в 10 строках пропущен кусок про блокировки и обработку ошибок.

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

Вот именно. Значит, если новая технология вытесняет старую, то она настолько удобнее, что это перевешивает удобство от распространённости. Например, Linux на персональном компьютере удобнее чем Windows, но не настолько, поэтому держится в своей нише.

SELECT count(*) FROM t1 JOIN t2 ON t1.id=t2.id

Пфф

cout<<(t1|t2).find([](decltype((t1|t2)::row)& a){return a->first->id == b->first->id;}).size();

Значит, если новая технология вытесняет старую, то она настолько удобнее, что это перевешивает удобство от распространённости.

а если не вытесняет, значит, это ненужный язык-велосипед

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

cout<<(t1|t2).find([](decltype((t1|t2)::row)& a){return a->first->id == b->first->id;}).size();

Это точно хоть сколько-то адекватно? В смысле, (t1|t2) разве не вернёт полное декартово произведение всех строк двух таблиц?

а если не вытесняет, значит, это ненужный язык-велосипед

Именно так. Вот, например, Zig или Nim. В среднем удобнее. Но не настолько, чтобы отказаться от привычной инфраструктуры и тратить время на их изучение. А вот Go, как ни странно, вытесняет.

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

При наличии индексов дешёвая. И, в общем случае, если приходится придумывать как избавиться от джойна, то приходится сразу придумывать и как избавиться от СУБД.

Короче, вам нужно придумать пример, в котором одна строка sql соответствует не 10 строкам кода, а 100.

Допиши туда код для оптимистичной блокировки, будет все 100. Замечу, что десятичный порядок — 10, двоичный порядок — два. Думаю, следующим заказом будет «нужно придумать пример, в котором одна строка sql соответствует не 100 строкам кода, а 1000», что уж мелочиться.

join тоже вернёт. в этом и прикол

При наличии индексов дешёвая.

ну вот ещё об индексах задумываться, целостности, правильном удалении...

При наличии индексов дешёвая.

и нет, всё равно иногда недостаточно дешёвая, как показала практика

Допиши туда код для оптимистичной блокировки, будет все 100.

э нет, это уже производительность, а она зависит от компилятора/библиотеки, а не языка, так-то и для вашего языка (какого, кстати?) можно сделать компилятор, который сам блокировки будет выставлять

Замечу, что десятичный порядок — 10

Да, но вы не сэкономили время программиста в 10 раз. Вы просто сэкономили число строк кода в 10 раз. Оно не прямо пропорционально. Часто даже наоборот - больше строк кода - меньше время разработки.

И после этого SQL вытеснил dBase даже без клиент-сервера (SQLite).

Где вытеснил, куда вытеснил? NoSQL локальных баз с хорошей поддержкой валом на рынке. Причину я выше уже написал: SQL давал совместимость с клиент-сервером, в то время, как с возникновением распределенных баз приеритетом стал отказ от SQL, что определело рост популярности NoSQL баз в том числе в чисто локальном варианте. MS Access, к слову, до сих пор довольно активно используется, а она ведь поддерживает оба режиме: NoSQL и SQL - и то, SQL там не ANSI-совместимый.

SELECT t1
GO TOP
c = 0
SCAN FOR !EOF()
SELECT t2
LOCATE FOR id=t1.id
IF !EOF() AND id=t1.id
c = c + 1
ENDIF
ENDSCAN

Это PSQL-подобный синтаксис, и он довольно тяжелый. В продвинутых инструментах просто создается таблица t1 и к ней присобачивается NestedTable с указанием двух полей - вот и вся нереальная сложность.

join тоже вернёт. в этом и прикол

Нет. Даже без оптимизатора «SELECT count(*) FROM t1 JOIN t2 ON t1.id=t2.id» не «SELECT count(*) FROM t1 JOIN t2 WHERE t1.id=t2.id». А с учётом оптимизатора даже условия WHERE накладываются до объединения где возможно. А если нормальный оптимизатор, то на count(*) будет сгенерировано что-то вроде:

tmp = hash (key: typeof id, value : (int c1, int c2) default (0,0));
for(r : t1) { tmp[r.id].c1 = c1 }
for(r : t1) { tmp[r.id].c2 = c2 }
for(r : tmp) { sum += r.c1*r.c2 }

ну вот ещё об индексах задумываться, целостности, правильном удалении...

Так в SQL как раз не надо задумываться. Один раз его сделал, а дальше компилятор SQL задумывается. А вот при ручном обходе, надо все индексы указывать вручную.

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

В пределе это будет SQL СУБД в виде библиотеки. Может с другим синтаксисом. То есть можно вместо «t1 JOIN t2» писать (t1|t2), но как тогда писать «t1 LEFT JOIN t2», как указать переименование полей, если в t1 и t2 с одинаковыми именами поля?

Кстати, в

cout<<(t1|t2).find([](decltype((t1|t2)::row)& a){return a->first->id == b->first->id;}).size();

Это PSQL-подобный синтаксис, и он довольно тяжелый. В продвинутых инструментах просто создается таблица t1 и к ней присобачивается NestedTable с указанием двух полей - вот и вся нереальная сложность.

Эти продвинутые инструменты появились после SQL. А «PSQL-подобный синтаксис» — это стандартный синтаксис dBase и его семейства. Был задолго до SQL. А если ещё раньше, то там RPG и COBOL, где синтаксис ещё тяжелее.

Где вытеснил, куда вытеснил? NoSQL локальных баз с хорошей поддержкой валом на рынке.

Какая из них более распространена, чем SQLite? Блин, даже в браузер и файлы журналов 1С уже SQLite запихнули (хотя он там как собаке пятая нога).

MS Access, к слову, до сих пор довольно активно используется, а она ведь поддерживает оба режиме: NoSQL и SQL - и то, SQL там не ANSI-совместимый.

COBOL тоже активно используется. Сколько проектов, начатых после 2010 на MS Access?

Как минимум могут быть защищены от типовых ошибок из старых языков.

Да, я про Rust и lifetimes.

Эти продвинутые инструменты появились после SQL. А «PSQL-подобный синтаксис» — это стандартный синтаксис dBase и его семейства. Был задолго до SQL. А если ещё раньше, то там RPG и COBOL, где синтаксис ещё тяжелее.

Давай не путать 1950 год и 2010 год. Железо было совершенно другое, требования были другие. В 1950-1960 SQL-сервер был крайним расточительством, потому совершенно неприемлим. По мере развития компьютерной техники появилась возможность жертвовать частью быстродействия ради части удобства - так в том числе появился SQL. SQL был далеко не единственным средством для орагнизации СУБД, просто в какой-то момент истории он оказался востребован для разработки систем клиент-сервер, немного выходя за рамки этой сферы, как это происходит со всеми широко используемыми технологиями. Но даже в пике популярности SQL было не единственным средством, и тот же Borland в это же время довольно неплохо себя чувствовал со своими NoSQL инструментами.