Телеграмм чат группы docsascode страница 777

Size: a a a

DocOps-сообщество

2020 December 12

Поиск с учётом словоформ для китайского, полагаю, не имеет ничего общего с поиском с учётом словоформ для русского или финского.

источник

02:04пожаловаться #1

Phil Delgyado in DocOps-сообщество

Тогда работа с текстом (той же документацией, если перестать оффтопить) можно будет описывать кодом.
"Найти всюду сценарии, описывающие аутентификацию, заменить описание ввода пароля на описание ввода пароля и OTP по примеру из ..."

источник

02:05пожаловаться #2

Phil Delgyado in DocOps-сообщество

На всех языках сразу, конечно )

источник

02:06пожаловаться #3

Phil Delgyado in DocOps-сообщество

Ну и всякие "найди в этих 5000 страниц, где описываются разные сценарии работы с http/2"

источник

02:06пожаловаться #4

Max in DocOps-сообщество

Phil Delgyado

Это уже звучит как фреймворк на основе той воображаемой библиотеки. Но как это должно повлиять на структуру языка, по прежнему непонятно.

источник

02:07пожаловаться #5

Phil Delgyado in DocOps-сообщество

На структуру какого языка?

источник

02:07пожаловаться #6

Phil Delgyado in DocOps-сообщество

Это скорее use cases. а вот как оно должно выглядеть - я не знаю. Если бы знал, то может быть сделал бы )

источник

02:08пожаловаться #7

Max in DocOps-сообщество

Phil Delgyado

На структуру какого языка?

Программирования. Мы с этого начали разговор, что нет специального языка для работы с текстами

источник

02:08пожаловаться #8

Phil Delgyado in DocOps-сообщество

Ну, тут как в SQL, все идет от внутренней модели и сценариев использования.

источник

02:09пожаловаться #9

Phil Delgyado in DocOps-сообщество

У того же SQL изначально был подход "бухгалтер сам себе построит выписку". И строили )

источник

02:09пожаловаться #10

Phil Delgyado in DocOps-сообщество

Т.е. это был язык для конечных (но опытных) пользователей, не только программистов.

источник

02:09пожаловаться #11

Max in DocOps-сообщество

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

источник

02:10пожаловаться #12

Phil Delgyado in DocOps-сообщество

Ну, это опять оффтопик, но мне-то sql нравится )

источник

02:12пожаловаться #13

Phil Delgyado in DocOps-сообщество

То есть для выборок и модификации данных лучше пока так и нет, увы.

источник

02:13пожаловаться #14

Max in DocOps-сообщество

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

источник

02:14пожаловаться #15

Phil Delgyado in DocOps-сообщество

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

источник

02:15пожаловаться #16

Phil Delgyado in DocOps-сообщество

При этом я не вижу, конечно, разницы между
tables(a,b).select(a.a1,b.b2).where(a.a>3).and(a.id=b.id) и SQL
SQL привычнее, но примерно тоже

источник

02:17пожаловаться #17

Viktor Alexandrov in DocOps-сообщество

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

источник

09:02пожаловаться #18

Andrey in DocOps-сообщество

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

источник

10:23пожаловаться #19

Andrey in DocOps-сообщество

Phil Delgyado

При этом я не вижу, конечно, разницы между
tables(a,b).select(a.a1,b.b2).where(a.a>3).and(a.id=b.id) и SQL
SQL привычнее, но примерно тоже

Хотя🤔посмотрел, задумался, действительно удобно читается

источник

10:27пожаловаться #20