Если решать только исходную, не обобщённую задачу и не забывать про name:
my @names = map {$_->name} @fields;
, что, учитывая, то, что блок в map — закамуфлированная анонимная функция, аналогично второму варианту на js.
Преимущество перла в том, что настолько удобный map, делает ненужным такой дополнительный уровень абстракции как списковые выражения. А избавление от лишней абстракции при той же читаемости и выразительности — гибкость забесплатно.
В js нормальный ООП если убрать new. Просто необычный. И он проще, т.к. выпадает такой элемент как классы. Поэтому для легкого языка прототипное ООП — преимущество.
Сравнение некорректно. Если есть возможность в IE как бы включить поддержку недостающей технологии, то этим пользуются, если нет, то всё равно париться и уже не имеет смысл использовать border-radius для остальных браузеров.
Пока будет требоваться кросскомпиляция выигрыша в производительности не получится. Т.е. по настоящему преимущество в производительности получиться только когда все основные браузеры станут поддерживать его нативно. Таким образом, производительность никак не повлияет на его популярность.
Стобы Dart/Dash взлетел он должен быть лучшим языком чем JS, причём заметно лучшим, при этом оставаясь простым.
select ... from a join b (a.id = any(b.descendants)) -- b.descendants - int[]
insert into ... select ... from ...
update ... from (values ...) where ...
в таком духе.
Плюс несколько случаев, которые и на джанго можно сделать, просто ради простоты или эффективности написали SQL.
Использовать везде один ORM, а в качестве fallback-a другой — это ПП. Тем более, что иногда ещё и до SQL будет доходить. Сейчас не поленился грепнул один свой проект на джанге:
Запросов через ORM — 500 (не считаем Model.save(), .delete(), related ацессоры, вариации одного запроса с разными фильтрами, порядком, count() на тот же queryset).
Запросов на SQL — 15.
Есть ещё SQL запросы к внешним базам, DDL, интроспекция и платформная специфика, их выкидываем потому как это вне компетенции ORM.
В итоге ORM покрывает 97% запросов при весьма либеральном подходе, при переходе на другую базу проще подправить эти 15 запросов (если придётся), чем всё приложении заранее писать на другом ORM. Пусть SQLAlchemy покроет 99%, вместо 15 SQL запросов у меня будет 5, зато все те 500 будут на более низкоуровневом SQLAlchemy, мой код сразу станет гораздо менее простым.
Это всё к автору, который считает, что мы со своим Django ORM неизбежно будем тыкаться в его ограничения.
Возможно у кого-то проект другой и запросы другие, тогда, может быть, SQLAlchemy там будет лучше.
Напоследок ещё один гвоздь в SQLAlchemy — кеширование. Сложные запросы кешировать тяжело, они зависят от большого количества вещей и поэтому их сложнее инвалидировать (или чаще). Кроме того, запрос к кешу, как правило, дешев, поэтому запрос разбирается на кусочки, каждый из которых кешируется и инвалидируется отдельно. Сложные запросы уходят — для простых запросов лучше ORM попроще, который сделает более читаемым и более DRY оставшийся код.
Выбирать джанго из-за админки — не глупо, экономит очень много времени, и даже если она вам не подходит для отдельного приложения или модели, то нужно будет переписать только для них, а для всего остального будет работать стандартная. Да и возможности кастомизации админки джанги весьма велики, так что полностью переписывать возможно и не понадобиться.
У нас так. Раз в месяц подводятся итоги и освещаются/обсуждаются планы. Плюс новые сотрудники представляются — кто они такие и что делают. Да и в другое время всё весьма открыто.
my @names = map {$_->name} @fields;
, что, учитывая, то, что блок в map — закамуфлированная анонимная функция, аналогично второму варианту на js.
Преимущество перла в том, что настолько удобный map, делает ненужным такой дополнительный уровень абстракции как списковые выражения. А избавление от лишней абстракции при той же читаемости и выразительности — гибкость забесплатно.
my @ips = $text =~ m/\d+\.\d+\.\d+\.\d+/g;
Стобы Dart/Dash взлетел он должен быть лучшим языком чем JS, причём заметно лучшим, при этом оставаясь простым.
select ... from a join b (a.id = any(b.descendants)) -- b.descendants - int[]
insert into ... select ... from ...
update ... from (values ...) where ...
в таком духе.
Плюс несколько случаев, которые и на джанго можно сделать, просто ради простоты или эффективности написали SQL.
select ... for update;Запросов через ORM — 500 (не считаем Model.save(), .delete(), related ацессоры, вариации одного запроса с разными фильтрами, порядком, count() на тот же queryset).
Запросов на SQL — 15.
Есть ещё SQL запросы к внешним базам, DDL, интроспекция и платформная специфика, их выкидываем потому как это вне компетенции ORM.
В итоге ORM покрывает 97% запросов при весьма либеральном подходе, при переходе на другую базу проще подправить эти 15 запросов (если придётся), чем всё приложении заранее писать на другом ORM. Пусть SQLAlchemy покроет 99%, вместо 15 SQL запросов у меня будет 5, зато все те 500 будут на более низкоуровневом SQLAlchemy, мой код сразу станет гораздо менее простым.
Это всё к автору, который считает, что мы со своим Django ORM неизбежно будем тыкаться в его ограничения.
Возможно у кого-то проект другой и запросы другие, тогда, может быть, SQLAlchemy там будет лучше.
Напоследок ещё один гвоздь в SQLAlchemy — кеширование. Сложные запросы кешировать тяжело, они зависят от большого количества вещей и поэтому их сложнее инвалидировать (или чаще). Кроме того, запрос к кешу, как правило, дешев, поэтому запрос разбирается на кусочки, каждый из которых кешируется и инвалидируется отдельно. Сложные запросы уходят — для простых запросов лучше ORM попроще, который сделает более читаемым и более DRY оставшийся код.
select_related() с явным указанием что джойнить работает отлично.