В чём суть «ужасности»? Список источников в своей секции, список условий — в своей.
Так же как по секциям расположены описание полей на выходе, сортировка, группировка.
Нужно осознать, что SQL — это язык описания запроса, а не язык «почти естественного» общения человека с компьютером.
Все те же претензии «на первый взгляд кажутся легкими (читается как будто по-английски!), но почему-то приходится гуглить» — справедливы для того же Си или любого другого языка. Английские термины в качестве ключевых слов — облегчают их мнемоническое запоминание, но не более того. Они не являются эквивалентом конструкций естественного языка.
SELECT members.firstname || ' ' || members.lastname
AS "Full Name"
FROM borrowings
INNER JOIN members
ON members.memberid=borrowings.memberid
INNER JOIN books
ON books.bookid=borrowings.bookid
WHERE borrowings.bookid IN (SELECT bookid
FROM books
WHERE stock>(SELECT avg(stock)
FROM books))
GROUP BY members.firstname, members.lastname;
SELECT
members.firstname || ' ' || members.lastname AS "Full Name"
FROM
borrowings, members, books
WHERE
members.memberid=borrowings.memberid AND
books.bookid=borrowings.bookid AND
books.stock > (SELECT avg(stock) FROM books)
GROUP BY
members.firstname,
members.lastname;
Чем так хорош идеевский плагин? Тем что он даёт возможность использовать Идею.
Того минимума, что есть в плагине — достаточно для сносной работы, но при этом открываются не бедные и привычные по другим IDE от IntelliJ возможности и workflow, которые окупают все недостатки пока ещё слабой поддержки Rust.
Вы просто попробуйте включить многопроцессный режим — он давно уже доступен для тестирования. Проблемы с выжиранием памяти нет, вкладки также грузятся по необходимости, при этом отзывчивость — небо и земля с тем, что без него. Падений так же не наблюдается.
Сервер обрабатывает подключения тысячами — процессы становятся дорогими, при этом ради экономии из него вырезаются всякие ненужные свистелки — один процесс справляется с большим количеством однотипных задач с кешируемым результатом. На клиенте всё наоборот — одновременных соединений/работающих вкладок единицы, при этом каждая страница обвешана свистелками по самое дальше некуда. Плюс сейчас тенденция часть работы переносить с сервера на клиент.
Изначально заявлялось об изоляции процессов и повышенной безопасности в связи с этим. Не знаю насчёт безопасности, но стабильности это браузеру не добавило.
Всё сильно зависит от того, что за логика. Структуры данных в питоне очень даже опитимизированы, много всего реализованного на Си. В итоге питон — это гибкая скриптовая склейка для Си-кода. Не стоит переоценивать объём медленного чисто-питоньего кода в программе. Но если всё-же решитесь использовать инструменты вроде SQLAlchemy, то да, — питон будет исключительно медленным и PyPy не сильно спасёт.
Параноидальность пользователей не даст распространиться среди параноидальных пользователей, не более того. Учитывая, что большинство — пофигисты, а целевая аудитория — пользователи с недостаточным опытом, нуждающиеся в подсказках — распространение скорее будет достаточно быстрым (если только это действительно будет полезно).
Ситуация усложняется тем, что приставка «при» в данном случае таки «немного исключение». В будущем времени пишется наоборот без «й»: «придёт», хотя «обойдёт», «перейдёт», «зайдёт», «выйдет» и т.д. И это сбивает с толку.
Вот это уже интересно. А есть примеры проектов, распределяющих бизнес-логику одной локации на несколько серверов? Было бы интересно почитать как они с этим живут.
Мне кажется здесь скорее оптимизация уйдёт в недра Cython, либо иных низкоуровневых решений, свободых от GIL, чем в распределённую среду, которую проектировать и обслуживать сразу на порядок сложнее. Обычно онлайн игры стремятся наоборот изолировать наименьшее количество взаимодействующих игроков на отдельном шарде.
Не знаю, как у нового поколения, а как человек, начинавший с паскаля в 90-х и десяток лет посвятивший Делфи и перепробовавший разных языков, скажу: Rust весьма нагружен низкоуровневым синтаксисом, позволяющим контролировать многое. Это делает его итак не самым лаконичным языком. Поэтому компактное описание управляющих структур, возможность выносить многое «за скобки» макросов — тут только идёт на пользу языку. А в целом — «сахара» как такового не так уж и много. Хотя, конечно, всё относительно, но сравнивать с любимым языком, не вникнув в изучаемый — не перспективно. Первое время изучая новый язык тащишь в него привычный подход и отработанные шаблоны кода, которые обычно плохо ложатся на внутреннюю логику другого языка, поэтому на предвзятый взгляд этот «другой язык» может казаться странным и уродливым, а местами очень нелогичным. Этот этап так или иначе нужно пройти, прежде чем сделать объективный вывод.
Сложно сказать, в match получаются очень аккуратные таблички, значительно упрощающие визуальный разбор.
Лапша из if() elseif() или case: break — явно проигрывает по читабельности.
Но, имхо, это тоже сложнее читается, чем лаконичная секция FROM и подробная WHERE.
не могу не согласиться — здесь просто месиво операторов вместо лаконичного и визуально структурированного перечисления.
Так же как по секциям расположены описание полей на выходе, сортировка, группировка.
Все те же претензии «на первый взгляд кажутся легкими (читается как будто по-английски!), но почему-то приходится гуглить» — справедливы для того же Си или любого другого языка. Английские термины в качестве ключевых слов — облегчают их мнемоническое запоминание, но не более того. Они не являются эквивалентом конструкций естественного языка.
Того минимума, что есть в плагине — достаточно для сносной работы, но при этом открываются не бедные и привычные по другим IDE от IntelliJ возможности и workflow, которые окупают все недостатки пока ещё слабой поддержки Rust.
Мне кажется здесь скорее оптимизация уйдёт в недра Cython, либо иных низкоуровневых решений, свободых от GIL, чем в распределённую среду, которую проектировать и обслуживать сразу на порядок сложнее. Обычно онлайн игры стремятся наоборот изолировать наименьшее количество взаимодействующих игроков на отдельном шарде.
Лапша из if() elseif() или case: break — явно проигрывает по читабельности.
Это выражение всегда истинно:
Стоит немного подкорректировать статью