Главное чучелко — это то, что невозможно по-настоящему крепко подружить математику и не-математику.
Что вы имеете в виду под не-математикой? ООП разве не построено на основе теории множеств?
Как-то сразу приучил себя предохраняться.
Так ведь и не надо приучать, если можно пользоваться инструментами, исключающими ошибки.
Чисто по практике: рефакторинг с отказом от ORM зачастую в разы улучшает производительность именно за счёт более оптимизированной работы с СУБД.
Разумеется, у меня нет такого опыта − переписывать проект с выбрасыванием из него ORM, я даже не слышал о таких проектах, да и не стал бы в таком участвовать.
Мой практический опыт говорит мне, что, во-первых, на один неоптимальный запрос, полученный с помощью ORM, приходится сотня запросов, которые ORM сгенерирует оптимальнее, чем программист с первой попытки, и уже этим использование ORM оправдывает себя. Во-вторых, отдельные запросы всегда можно оптимизировать, и тут обычно есть выбор: улучшить код, использующий ORM, либо включить «сырой» SQL в конкретный запрос. Об отказе от ORM в обоих случаях речи не идёт. Ну, и, в-третьих, у любой оптимизации есть границы применимости. А то ведь можно всё на Ассемблере переписать, без SQL, будет ещё быстрее.
А что миграции? Вы о чём? Об ETL или об автоматическом апдейте структуры базы?
Базовую идею ООП можно попытаться сформулировать примерно так: поскольку мир состоит из объектов, то его, этот мир, было бы удобно моделировать созданием объектов внутри программной системы.
Ну зачем так передёргивать? Человек рассматривает окружающий мир как совокупность объектов, поэтому программировать ему тоже может быть удобней при помощи объектов.
ООП − это плохо, поэтому ORM − тоже плохо. Однако ООП широко применяется на практике, поэтому нам придётся с ним считаться. Распространить тот же принцип практической применимости на ORM автор почему-то не хочет,
ORM не является проблемно-ориентированным, поэтому не нужен,
задачу независимости программы от конкретной СУБД уже решали раньше (на самом деле ODBC весьма хреново решает эту задачу по сравнению со многими ORM, ну да ладно),
абстрактный мэппинг − это слишком сложно, мы лучше сделаем много ситуационных мэппингов, типа «средний объём продаж за заданный период», и будем потом весь этот код поддерживать,
и т. д.
Разумеется, список проблем, которые решают (успешно, на практике) ORM у автора далеко не полон. Вот только наиболее очевидные для меня:
безопасность запросов (в смысле изоляции от пользовательского ввода),
оптимизация обращений к СУБД (каскадное конструирование запроса, отложенное выполнение),
миграции!
Лично мне прочувствовать пользу ORM на практике помогло написание нескольких небольших проектов на Python без ORM. Начав писать свой абстрактный уровень поверх MySQLdb, я понял, что занимаюсь ерундой. Сравнивая Django ORM, SQLAlchemy или PonyORM с тогдашними моими экзерсисами, я понимаю, что ORM − не кошмар и не гиря на ноге, а реальные помощники в работе, пусть и не идеальные.
Как сделать так, чтобы pip, установленный вместе с Python 3.6 c python.org, знал, где искать компилятор, либы и хедеры. Игрался с путями, менял версии − бесполезно. Windows детектится, компилятор − нетъ.
Конечно, конечно. Мне однажды было надо, я пару дней убил − не разобрался. Потом поставил mingw64 и сделал всё, что надо было, без разбирательств.
Потому что прыгать по сцене и кричать “Developers! Developers!” мы можем, а сделать систему удобной для разработчика − «У вас далеко не типичная задача, пройдите нахер, товарищ!»
Да, я хочу, чтобы их скачивали абсолютно все пользователи, как это делается в линуксах, макоси, BSD4.3-производных, Солярисе и т. д. Никого почему-то не смущает стандартный компилятор, только в Microsoft-мире все уверены, что без него лучше.
Хотя я не думаю, что набор CLI-средств разработки на самом деле должен весить гигабайты, в других системах всё на 2-3 порядка скромнее. Но тут Microsoft виднее, конечно.
Microsoft, да включите вы уже в Windows стандартный компилятор C (CLI), чтобы питонисту для установки любого пакета с C-расширением из исходников (или для написания своего) не надо было плясать с бубном и скачивать гигабайты VS. А как установить Python, мы уж как-нибудь сами разберёмся.
Вы не учитываете тот факт, что посетители Хабра − в основном профессионалы с синдромом самозванца. Они паникуют, когда возникает необходимость задать вопрос на форуме производителя компонента, или даже при виде даташита. Поэтому они заходят сюда за профессиональной информацией, надеясь, что она будет хорошо замаскирована под «как я провёл лето» и не вызовет приступа.
Исследование финских ученых-социологов показывает, что наследственность оказывает влияние на уровень заработка человека. По полученным результатам стало ясно, что для женщин генетические особенности определяют их доход на 40%, для мужчин — более чем на 50%.
Мне кажется, финские учёные социологи перепутали наследственность (из генетики) с наследованием (из юриспруденции).
1.1 What is a type system
A useful—though rough—distinction divides the world of programming languages into two parts:
Untyped — programs simply execute flat out; there is no attempt to check “consistency of shapes”
Typed — some attempt is made, either at compile time or at run-time, to check shape-consistency
Но это, в общем-то, частности. Я не понимаю вашей логики в целом. Если в Python нет типов, то как CPython отличает строку от числа? Что делает встроенная функция type?
Если в Python нет типов, значит, и классов там нет? Классы − это ведь частный случай типизации. Или если класс сконструирован в рантайме, то он не считается классом?
Ну давайте, давайте ссылаться на эту книгу. Я её раньше не читал, но теперь вот с удовольствием открыл. Но что-то не могу я в ней найти такого утверждения, что именно статический тайпчекер делает язык типизированным. Наоборот, типизированный язык определяется как
some attempt is made, either at compile time or at run-time, to check shape-consistency
У Python с этим всё в порядке:
>>> 1 + "a"
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'int' and 'str'
Как вообще это получается, по-вашему: ошибка типа есть, а типов нет? Где тут логика?
С каких это пор динамическая типизация − это «нет типов»? Нет типов в ассемблерах, в BCPL. Почитайте хотя бы вики для приличия: “Python uses duck typing and has typed objects but untyped variable names… Despite being dynamically typed, Python is strongly typed…”.
Windows лучше исключите из списка, не работает там Python по-нормальному. На этой платформе нет стандартного компилятора C, собрать сишный пакет для официального дистрибутива Python − то ещё приключение, поэтому чаще приходится подставлять костылики: либо «зверь-сиди» с своими суррогатами вместо нормальных PyPI и Virtualenv (Anaconda, ActivePython), либо оверхед в виде MinGW.
Конечно, Wheel-пакеты в своё время немного снизили накал страстей. Но, поскольку Microsoft ради Python за всю историю ни разу не пошевелил и пальцем (“Developers! Developers! Developers!”), для питонистов будет безопасней игнорировать эту платформу.
Ну, это уже отдельный вопрос. Хотя тоже имеет место быть.
Можно странный вопрос? Я знаю, что Раст популярный ЯП, но… зачем он нужен если есть Си/С++ на котором можно написать всё?
Это некая концептуальная проблема для меня, я ставил Раст, поигрался и бросил не найдя применения.
Можете привести примеры того, что легко-быстро-удобно делается на Расте и тяжело и громоздко на Си?
Так ведь и не надо приучать, если можно пользоваться инструментами, исключающими ошибки.
Разумеется, у меня нет такого опыта − переписывать проект с выбрасыванием из него ORM, я даже не слышал о таких проектах, да и не стал бы в таком участвовать.
Мой практический опыт говорит мне, что, во-первых, на один неоптимальный запрос, полученный с помощью ORM, приходится сотня запросов, которые ORM сгенерирует оптимальнее, чем программист с первой попытки, и уже этим использование ORM оправдывает себя. Во-вторых, отдельные запросы всегда можно оптимизировать, и тут обычно есть выбор: улучшить код, использующий ORM, либо включить «сырой» SQL в конкретный запрос. Об отказе от ORM в обоих случаях речи не идёт. Ну, и, в-третьих, у любой оптимизации есть границы применимости. А то ведь можно всё на Ассемблере переписать, без SQL, будет ещё быстрее.
Второе.
Ну зачем так передёргивать? Человек рассматривает окружающий мир как совокупность объектов, поэтому программировать ему тоже может быть удобней при помощи объектов.
Дальше, впрочем, не лучше.
Есть отличная статья в Википедии: Object-relational impedance mismatch. Там собрана серьёзная, качественная критика ORM:
Но уважаемый maslyaev вместо критики предлагает нам набор соломенных чучелок:
Разумеется, список проблем, которые решают (успешно, на практике) ORM у автора далеко не полон. Вот только наиболее очевидные для меня:
Лично мне прочувствовать пользу ORM на практике помогло написание нескольких небольших проектов на Python без ORM. Начав писать свой абстрактный уровень поверх MySQLdb, я понял, что занимаюсь ерундой. Сравнивая Django ORM, SQLAlchemy или PonyORM с тогдашними моими экзерсисами, я понимаю, что ORM − не кошмар и не гиря на ноге, а реальные помощники в работе, пусть и не идеальные.
А вы точно знаете, что значит это слово?
А старый или не старый − это в данном случае неважно. Главное, чтобы собирал си-расширения.
Конечно, конечно. Мне однажды было надо, я пару дней убил − не разобрался. Потом поставил mingw64 и сделал всё, что надо было, без разбирательств.
Потому что прыгать по сцене и кричать “Developers! Developers!” мы можем, а сделать систему удобной для разработчика − «У вас далеко не типичная задача, пройдите нахер, товарищ!»
Хотя я не думаю, что набор CLI-средств разработки на самом деле должен весить гигабайты, в других системах всё на 2-3 порядка скромнее. Но тут Microsoft виднее, конечно.
Мне кажется, финские учёные социологи перепутали наследственность (из генетики) с наследованием (из юриспруденции).
Но это, в общем-то, частности. Я не понимаю вашей логики в целом. Если в Python нет типов, то как CPython отличает строку от числа? Что делает встроенная функция
type?Если в Python нет типов, значит, и классов там нет? Классы − это ведь частный случай типизации. Или если класс сконструирован в рантайме, то он не считается классом?
У Python с этим всё в порядке:
Как вообще это получается, по-вашему: ошибка типа есть, а типов нет? Где тут логика?
Конечно, Wheel-пакеты в своё время немного снизили накал страстей. Но, поскольку Microsoft ради Python за всю историю ни разу не пошевелил и пальцем (“Developers! Developers! Developers!”), для питонистов будет безопасней игнорировать эту платформу.
Ответите?