class A:
pass
class B:
pass
print(print(type(A) == type(B))) # False
Другое дело, что можно экземпляры классов преобразовать к простым словарям и тем самым легко перейти к структурным типам. Но сами по себе классы A и B различны.
Номинативность предполагает тождественность по имени, но в контексте интерфейсов, при динамической типизации нас интересует то, подходит ли объект по структуре, а не по имени.
Да, именно так. В Python последствия того, что классы номинативны практически не заметны, поскольку, как вы написали, в подавляющем большинстве случаев от объектов нам нужны методы и поля, а не имена классов.
Я пожалуй ворвусь, и скажу, что всё-таки Rust нацеливается на то, чтобы сдвинуть C++. Это будет сделать трудно, из-за огромного количества легаси, но тут C++весьма неплохо сам себе помогает.
Да, об этом статья и говорит: у AuthUser, с которым вам приходится работать, есть тип, и у этого типа есть определение, но оно (определение) раскидано кусочками по всему коду, который использует этот объект тем или иным способом, то есть неявно.
Но если добавить ещё одно обязательное требование — безопасность (в слабом смысле, то есть когда объекты или другие сущности изолированы друг от друга), то уже от проверок в рантайме уже не уйти, почти каждый доступ к объекту сопровождается накладными расходами, разве не так?
Конечно, есть исследования по gradual typing, когда система построенная на динамических типах постепенно обрастает статическими типами, и это позволяет постепенно избавляться от рантайм-проверок, но у этого подхода тоже есть существенные недостатки (см исследования учёного по имени Matthias Felleisen).
Это связано не с трендом, а с выводом типов в различных контекстах (объявление локальной переменной — это лишь один из них).
Когда создавали C, о выводе типов не задумывались, а когда задумались, то позже, в C++, вынуждены были лепить костыли.
Вы что-ли не вовлечены в товарно-денежные отношения и отрицаете элементарые знания, наблюдаемые везде и всюду?
Питаетесь овощами выращенной на своём огороде без применения промышленно произведённых орудий труда, живёте в землянке, построенной без применения орудий труда и обучаете детей выживанию в условиях дикой природы, так? Стоп, кто вам дал доступ в интернет!?
Спасибо за замечание. Я, вдобавок, ещё неоднократно слышал, что мол теория прибавочной стоимости не применима к IT индустрии (!), ну из этого дальше разворачивается вывод, что экономика устроена по-другому, классов нет и Маркс неактуален.
Но если серьёзно, время Hadoop уже уходит, и Spark теперь de-facto стандартный инструмент для обработки больших данных. Сам Hadoop может быть интересен только в виде hdfs + yarn, однако и тут у него есть серьёзные конкуренты в лице k8s и mesos. Короче, в вашем списке Hadoop лишний, а наоборот, не хватает Spark
Плюсовать не могу, я в-основном RO, но ваша статья заставила всколыхнуться мою душу. Очень много тормозов для тех шагов, о которых вы пишете, но безусловно есть над чем подумать. Спасибо за статью!
Совместимость с C поддеживается, а нативный растовый ABI не слишком нужен в условияк сборки через cargo.
Но пока слишком велик риск допустить архитектурную ошибку. Я надеюсь, разработчики запилят GATы, а сейчас активно пилятся const-generics и другие фичи, и заморозить ABI значит обратить всё в legacy. Я лучше буду мучиться с перекомпиляцией пока.
Вычислительная математика (перемножения матриц, решения СЛАУ), игры, компьютерная графика, обработка сигналов, вычисления в ограниченной памяти.
Тут всё же надо признать, что мутабельность важна, но с точки зрения заблаговременной защиты от ошибок, мутабельность не должна быть по умолчанию. (Вот как в современных языках, вроде Раста или Хаскеля)
Хорошая статья. Я считаю, сложность программирования на Хаскеле сильно преувеличена, как и простота программирования на Го. Из-за императивной сущности языка, отсутствия иммутабельности и хорошей типизации граблей там предостаточно. Так, чтобы эффективно использовать Го, необходимо изучить мануал Effective Go, и понимать модель вычислений в Go, например Understanding real-world concurrency bugs in Go.
Мне в variant сильно не нравится get, который переносит ошибку типов в рантайм. Объехать это можно визитором, но с ним кот становится совсем уж громоздким. Не хватает паттерн-матчинга по-человечески. pastebin.com/DuZkyDBm
Да, вполне номинативны.
Другое дело, что можно экземпляры классов преобразовать к простым словарям и тем самым легко перейти к структурным типам. Но сами по себе классы
AиBразличны.Да, именно так. В Python последствия того, что классы номинативны практически не заметны, поскольку, как вы написали, в подавляющем большинстве случаев от объектов нам нужны методы и поля, а не имена классов.
Я пожалуй ворвусь, и скажу, что всё-таки Rust нацеливается на то, чтобы сдвинуть C++. Это будет сделать трудно, из-за огромного количества легаси, но тут C++весьма неплохо сам себе помогает.
Совсем недавно встретился вот такой баг в современном C++ (который отчасти фича): https://wandbox.org/permlink/7sbsqzhbo0o7dOse
Спасибо, хорошая статья, особенно понравилось про пацифизм!
Да, об этом статья и говорит: у
AuthUser, с которым вам приходится работать, есть тип, и у этого типа есть определение, но оно (определение) раскидано кусочками по всему коду, который использует этот объект тем или иным способом, то есть неявно.Но если добавить ещё одно обязательное требование — безопасность (в слабом смысле, то есть когда объекты или другие сущности изолированы друг от друга), то уже от проверок в рантайме уже не уйти, почти каждый доступ к объекту сопровождается накладными расходами, разве не так?
Конечно, есть исследования по gradual typing, когда система построенная на динамических типах постепенно обрастает статическими типами, и это позволяет постепенно избавляться от рантайм-проверок, но у этого подхода тоже есть существенные недостатки (см исследования учёного по имени Matthias Felleisen).
Это связано не с трендом, а с выводом типов в различных контекстах (объявление локальной переменной — это лишь один из них).
Когда создавали C, о выводе типов не задумывались, а когда задумались, то позже, в C++, вынуждены были лепить костыли.
Такое ощущение, что под термином "марксизм" вы используете ярлык, некоторое пугало, без знани о том, что это такое.
Вы что-ли не вовлечены в товарно-денежные отношения и отрицаете элементарые знания, наблюдаемые везде и всюду?
Питаетесь овощами выращенной на своём огороде без применения промышленно произведённых орудий труда, живёте в землянке, построенной без применения орудий труда и обучаете детей выживанию в условиях дикой природы, так? Стоп, кто вам дал доступ в интернет!?
Спасибо за замечание. Я, вдобавок, ещё неоднократно слышал, что мол теория прибавочной стоимости не применима к IT индустрии (!), ну из этого дальше разворачивается вывод, что экономика устроена по-другому, классов нет и Маркс неактуален.
Ну и зоопарк развели в этих ваших бигдатах :-))
Но если серьёзно, время Hadoop уже уходит, и Spark теперь de-facto стандартный инструмент для обработки больших данных. Сам Hadoop может быть интересен только в виде hdfs + yarn, однако и тут у него есть серьёзные конкуренты в лице k8s и mesos. Короче, в вашем списке Hadoop лишний, а наоборот, не хватает Spark
Плюсовать не могу, я в-основном RO, но ваша статья заставила всколыхнуться мою душу. Очень много тормозов для тех шагов, о которых вы пишете, но безусловно есть над чем подумать. Спасибо за статью!
Совместимость с C поддеживается, а нативный растовый ABI не слишком нужен в условияк сборки через cargo.
Но пока слишком велик риск допустить архитектурную ошибку. Я надеюсь, разработчики запилят GATы, а сейчас активно пилятся const-generics и другие фичи, и заморозить ABI значит обратить всё в legacy. Я лучше буду мучиться с перекомпиляцией пока.
Спасибо за две весёлых статьи: твою и о Rust :-)
Да, с вашим тезисом согласен. Я возможно не так прочитал, и подумал, что вы о мутабельности вообще, а не о мутабельности в голанге.
Вычислительная математика (перемножения матриц, решения СЛАУ), игры, компьютерная графика, обработка сигналов, вычисления в ограниченной памяти.
Тут всё же надо признать, что мутабельность важна, но с точки зрения заблаговременной защиты от ошибок, мутабельность не должна быть по умолчанию. (Вот как в современных языках, вроде Раста или Хаскеля)
Хорошая статья. Я считаю, сложность программирования на Хаскеле сильно преувеличена, как и простота программирования на Го. Из-за императивной сущности языка, отсутствия иммутабельности и хорошей типизации граблей там предостаточно. Так, чтобы эффективно использовать Го, необходимо изучить мануал Effective Go, и понимать модель вычислений в Go, например
Understanding real-world concurrency bugs in Go.
pastebin.com/DuZkyDBm