Зачем нужна статическая типизация?, или Вы всё врете!

Ага не проблема. У тебя есть лучшие ORM, то ты лепишь DTO, DAO, мапперы и репозитории ради DDD… Это не Clean, а Govno Architecture. Опять в мире джава, где не принято использовать ORM, оно уместно, но в более развитых языках - это все выглядит как варварство

но в более развитых языках - это все выглядит как варварство

А какие языки сейчас считаются «более развитыми»?

Друг интересуется ;)

Они все с недостатками. Мне питон так-то ВНЕЗАПНО не нравится я знаю все его недостатки как и PHP, JS и тп. Мне JS нравится, но он не подходит на роль универсального языка из-за отсутствия примитивного типа для представления «сырых» строк. Buffer - говно. Нем нет всяких методов типа split/replace… В том же PHP строки просто массив байт, поэтому strlen для юникода показывает не то что ожидается. И в Python 2 строки тоже были char[], но затем как в Java стали юникодными по дефолту… Ох уж эта ненавистная джава ряяяяяяяяяя. А сама Java - это лепить классы ради классов. В питоне они используюся там, где это уместно…

Если исходники любой параши на джаве открыть, то там будет такое:

int a = 42;
StringBuilder sb = new StringBuilder("{");
sb.append("\"a\":");
sb.append(a);
// ...

Просто портянки какой-то дрисни, потому что так быстрее нежели лепить под это дело целый класс. Убогий язык.

Толи дело JavaScript:

JSON.stringify({a: 42, ...})

Но тут главное осилить JavaScript Garden прочитать. И ни в коему случае не писать "42" == 42, за такое руки отрубают, нужно всегда использовать оператор ===, он сравнивает с учетом типов, НО нужно помнить, что 42 === 42.0 это true. Это язык где в отличии от Python для чисел единый тип Number, что тоже минус в общем-то

У тебя есть лучшие ORM

А когда ОРМ протухает, просто берём и переписываем всё (вообще всё) на новый ОРМ. Хей-хей.

в мире джава, где не принято использовать ORM

Ага, ну да.

А почему я везде DAO тогда вижу?

И тут контракты проскализывают, те свою явапетушню зачем-то в питон хотят притащить. Заговор - не иначе!

почему я везде DAO тогда вижу?

Кто тебя знает. Судя по сбору джейсонов вручную, ты смотришь какие-то лабы первокурсников %)

Про Spring-то хоть дошла до тебя молва?

Ты не вдупляешь. В питоне у нас все как:

# объявили модель
class User(db.Model):
  id = db.Integer(primary=True)
  username = db.String(unique=True)
  ...

# А потом ее используем
user = User.objects.get(42)

# Или в цикле
for user in User.objects.find(age > 18):
  ...

А Java код даже со спригом выглядит так:

@Entity
class User {}

public interface UserDao {}

class UserDaoImpl implements UserDao {}

class UserDaoService {} 

Короче нагромождение говна. И все это джавовое DDD вызывает лишь тошноту 🤮🤮🤮

А пример с JSON просто показательный: для парсинга объяви класс, для сериализации тоже класс… И типизация мешает: у тебя вместо int/float 64-битных куча мелких типов типа int8, uint8, …, uint64 (не про яву речь). Наверное, тут выше правильно написали, что динамическая типизация заставляет быть более внимательным, поэтому я даже представить не могу как у меня вместо строки может быть передано число…

А когда ОРМ протухает, просто берём и переписываем всё (вообще всё) на новый ОРМ. Хей-хей.

В питоне она одна по факту (угадай название). Ей 20 лет. Так же в NodeJS - Sequelize. В C# - Entity Framework… И альтернатив нет (упустим момент с Django и ее недо-ORM, косплеющую неназванную). Протухать нечему. Если ты конечно не аметист, выбравший маргинальщину какую интересную 3.5 землекопам. Так что java-подход с награмождением хероборы под предлогом, а вдруг менять будем УЩЕРБЕН

Js разумеется, панимаишь?

Я думал будут названы Хаскель, ну или C#…

JSON (Java Script Object Notation, те даже если он исчезнет, то это формату альтернатив нет, а значит он вошел в историю

Json придумал де6*л, который принципиально не включил комментарии. Но это еще пол беды.

А вот бОльшая проблема в том, что он не включил адекватный парсинг целочисленного типа, например:

• числа без явно указанной дробной части парсятся в целочисленный тип текущего языка (если такой тип есть).

Без этого значения в каком нибудь uint64_t превращаются в плавающий тип с потерей значащих цифр.

И более менее распространенные библиотеки тоже повторяют это поведение и парсят цисла в тип с плавающей запятой.

Протухать нечему

Ну дай-то б-г %)

Если прямо точно уверен, что ни один из фреймворков, к которому ты намертво приколотил свою модель предметной области, никогда не протухнет, не сломается или не потребует замены по другой причине (например, его ограничения начнут тебе адово мешать); или готов всё переписать в случае чего — пользуйся на здоровье, кто ж тебе запрещает.

Но надо понемать, что всё это только допущения, которые не для всех верны.

Если исходники любой параши на джаве открыть, то там будет такое

А зачем вообще именно так пишут? Ну common sense протестует и кричит же, что так не надо делать.

Дело в том что Java такая какая она есть потому что она специально спроектирована под использование в Waterfall-методологии разработки с первоначальным описанием всей системы архитектором и последующей реализацией этой системы программистами. Тот самый энтерпрайз в котором нужен относительно простой язык который заметает все под ковер абстракций. DAO в java как раз яркий пример этого.

В современном мире капитализм диктует свои условия - нужно быстрее ВЫБРОСИТЬ продукт на рынок, и не смотря на то что Waterfall - единственный расово верный подход к разработке, идет повсеместное внедрение MVP и гибких методологий разработки (Agile). Эта жажда скорости затрагивает не только методологию, цена ошибок меньше цены простоя во времени. В таком виде Java - говно, архитекты - не нужны, а связка программист+админ заменяется связкой кодер+девопс.

Это не плохо и не хорошо, это жизнь. Все равно в итоге в каких-то сферах все откатится обратно к водопаду, а где-то останется пародия на аджайл вида «ну мы не успели все таски в этом спринте потому что нам напихали дополнительных в середине спринта, поэтому просто переносим их в следующий спринт».

Критикуя JAVA в этом ключе вы критикуете то что молотком шурупы закручиваются не так аккуратно как отверткой.

В питоне она одна по факту (угадай название). Ей 20 лет. Так же в NodeJS - Sequelize. В C# - Entity Framework… И альтернатив нет (упустим момент с Django и ее недо-ORM, косплеющую неназванную). Протухать нечему. Если ты конечно не аметист, выбравший маргинальщину какую интересную 3.5 землекопам. Так что java-подход с награмождением хероборы под предлогом, а вдруг менять будем УЩЕРБЕН

Предлагаю взглянуть на ORM здорового человека, например, на Eloquent (PHP):

namespace App\MyModel\Model;

use Psr\Container\ContainerInterface;

class MyModel
{       
    protected $container;
    
    protected $db;

    protected $table;

    public function __construct(ContainerInterface $container) {
        $this->container = $container;
        $this->db        = $this->container->get('db');
        $this->table     = $this->container->get('settings')['table'];
    }
    
    public function getTotal() {

        return $this->db->table($this->table)
                        ->count();
    }

    public function getRowById($id) {
        
        return $this->db->table($this->table)
                        ->where('id', '=', $id)
                        ->get();
    }
}

Разве это не красиво? Этот код будет работать без изменений с MySQL, MariaDB, Postgres, SQLite и SQL Server. С небольшими изменениями он будет работать с Redis. С ходу есть конструктор структуры бд/запросов и миграции, поддерживает Container Interface PSR-11 что и позволяет добиться такой красоты.

Это не плохо и не хорошо, это жизнь.

Кстати, эта формула почему-то всегда, ВСЕГДА употребляется в контексте какого-то отвратительного говна.

Кстати, эта формула почему-то всегда, ВСЕГДА употребляется в контексте какого-то отвратительного говна.

Вы правы, использование Agile там где он не подходит, это говно.

Нене, я не про то, чем лично я считаю эджайл или там вотерфол, я про сам оборот.
«Это не хорошо и не плохо, это жизнь» всегда означает «это, разумеется, говно, но куда деваться». Забавляют меня такие вещи, аж смолчать не могу.

Я имел ввиду что приходится работать с тем что есть, т.к. глобально поменять эти тенденции мы не в силах (я точно не в силах). Можно конечно уйти в прекрасный мир розовых пони рассказывая что все надо переписать на Lisp, но как говорится, reality bites.

Это не ORM, а DAL (Database Abstract Layer).

ORM - это тупо связь между сущчностью User и таблицей users. Но это сильно утрировано. В питоне скорее паттерн ActiveRecord применяется… хотя алхимия это дата маппер

Это не ORM, а DAL (Database Abstract Layer).

Это и есть ORM здорового человека %)

Сущность предметной области (domain entity) описана отдельно, компонент для её сохранения/поиска в источнике данных (repository) отдельно, компонент источника данных (datasource) отдельно, компонент, собирающий это всё в работающую систему (DI/IoC container) отдельно.

В центре внимания — cущности и их отношения (предметная область); она не зависит ни от каких деталей реализации, над ней можно спокойно работать, не оглядываясь на сторонние библиотеки и фреймворки, которые ты не контролируешь. Ближе к периферии — источники данных и репозитории (которые зависят и от предметной области, и от источников данных).

Интерфейсы для взаимодействия между всеми ними описаны; можно легко добавлять, заменять и модифицировать реализации отдельных компонентов — главное следить, чтобы они соответствовали интерфейсам (выполняли свои контракты; написать для этого автотесты) и за направлением зависимостей. И тогда…

Добавить Редис/Кликхаус/localStorage/S3/1С как источник данных? Говно вопрос, добавляем реализацию и тесты, готово. Переписать реализацию репозитория для реляционных БД с нуля? Легко, правим один компонент, прогоняем тесты, готово. Перетряхнуть сущность? Тут, конечно, посложнее (то, что от неё зависит — репозитории — тоже придётся править), но бегать по всей кодовой базе с криками «что ещё я забыл поправить, курва» всё ещё не нужно.

Когда cистема не разделена на компоненты и никто не задумывался над её архитектурой — всё зависит от всего, при правке в одном месте что-то отваливается в совершенно другом; нельзя даже примерно сказать, сколько займёт конкретная задача (зависит от того, что отвалится в процессе её выполнения); непонятно, на что писать тесты, а на что не надо (следовательно, скорее всего, тесты писаться не будут вообще) — получается типичная разработка на петоне %)

Это и есть ORM здорового человека %)

Это кусок кала. Даже спорить не о чем.

В центре внимания — cущности и их отношения (предметная область); она не зависит ни от каких деталей реализации, над ней можно спокойно работать, не оглядываясь на сторонние библиотеки и фреймворки, которые ты не контролируешь. Ближе к периферии — источники данных и репозитории (которые зависят и от предметной области, и от источников данных).

Ага, в похапе, где чтобы подключить базу X нужно править php.ini и доставлять системные зависимости. Это язык, который придумывался как модуль для жопача, архитектурное уродство из него так и прет. Шаблонизатор на Perl, который зажил своей жизнью

Интерфейсы для взаимодействия между всеми ними описаны; можно легко добавлять, заменять и модифицировать реализации отдельных компонентов — главное следить, чтобы они соответствовали интерфейсам (выполняли свои контракты; написать для этого автотесты) и за направлением зависимостей. И тогда…

Они не нужны в языках с множественным наследованием. Такое же ненужное как портянки дрисни на джаве чтобы просто добавить сущность в базу.

Когда cистема не разделена на компоненты и никто не задумывался над её архитектурой — всё зависит от всего, при правке в одном месте что-то отваливается в совершенно другом; нельзя даже примерно сказать, сколько займёт конкретная задача (зависит от того, что отвалится в процессе её выполнения); непонятно, на что писать тесты, а на что не надо (следовательно, скорее всего, тесты писаться не будут вообще) — получается типичная разработка на петоне %)

Ты на нем никогда не писал. Архитектуру задает фреймворк. Так что с этим все в порядке. Где-то жестко (DRF), где-то не очень (FastAPI). s/петон/PHP/g было бы верным

Попався :) Я ошибся когда писал что архитекторов тут нет. Возможно, вы не занимаете позицию системного архитектора, но понимание вещей на уровне этого самого архитектора у вас точно есть.

[интерфейсы] не нужны

Архитектуру задает фреймворк

Архитектура называется «большой комок грязи» %)

вместо болтологии изучи вопрос, не пиши бред

Обезьяна с котом с умилением смотрят на первые шаги маленького котенка. Никогда такого не было и вот - опять.

не пиши бред

Нет, ну правда. Проектировать систему от конкретного хранилища данных — это как проектировать автомобиль от конкретного гаража. Если у какого-то покупателя гараж другой — надо проектировать с нуля новый автомобиль %)

Проектировать систему от конкретного хранилища данных — это как проектировать автомобиль от конкретного гаража

Двухэтажные автомобили или с очень высокой подвеской тоже никто не проектирует, так как они в гараж внезапно не влезут. Пустая болтология.

они в гараж внезапно не влезут

Автомобиль человеку нужен для того, чтобы он в гараж влезал, или всё-таки для чего-то другого?

А гаражи люди строят не под свой рост, продолжай в том же духе. Все это бредни из маня-книжек для макак, потому что пишут книги как и учат других те, кто как правило ничего не знают

бредни из маня-книжек для макак

Я не спорю, что множество небольших и средних проектов может более-менее успешно жить и развиваться, будучи построенными вокруг БД и не имея продуманной архитектуры. Но то, что ты можешь построить сельский туалет или дачный домик без проектирования и чертежей, совершенно не значит, что ты сможешь таким же образом построить гидроэлектростанцию или что-то типа Бурдж Халифа %)

К тому же разработка ПО — это очень коллективное занятие. Наличие высокоуровневого плана работ (привет, архитектура), написанного на общем, понятном для всех участников языке (привет, DDD) сильно влияет и на успешность проекта в целом, и на психологическое состояние и мотивацию команды. См. проект Вавилонская башня.

«строгая динамическая типизация» это пропагандистский термин.

вся «строгость» её заключается в том, что int в строку автоматом не конвертируется. и это пипец как неудобно, потому что он даже в Java конвертируется.

по факту в питоне всё то же самое, что в любой другой скриптоте, только менее удобно. по сути - ничем это не отличается от того же node.js. так что меня умиляют люди, которые рассказывают, что вот js мол убогий, а их питон - нееет.

а динамическая типизация удобна, потому что с ней код ПРОЩЕ. вы можете сколько угодно спорить, что это не так, потом баги, и вообще бла бла бла, но миллионы людей на скриптоте пишут, и пишут они на ней именно потому, что на ней писать ПРОЩЕ. а простота разработки - одна из самых главных, если не самая главная, ценность.

типизация с более-менее человеческим лицом это пожалуй только Go, где нет наследования, автоматические интерфейсы, и 99% переменных объявляются через автовывод типов. и то, меня лично всё равно не тянет веб писать на го, ибо есть нода.

привет, DDD

Я понял что мы говорим о разном DDD. Я не понимаю зачем сущности плодить без необходимости чтобы было 1:1 как в книжках по Java (Clean Architecture), а ты про «говорить с бизнесом на одном с ним языке»

зачем сущности плодить без необходимости

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

ты про «говорить с бизнесом на одном с ним языке»

Это как раз про DDD и его Ubiquitous Language. Clean Architecture немного про другое.

Тут какой-то цирк, а не форум. Постоянный срач ради срача без конструктива. Линуксоиды, половина которых сидит на винде или в дуалбуте. Программисты которые путают системный дизайн/архитектуру с паттернами проектирования и режут себе руки бритвой Оккама, электрики которые не знают что такое переходные процессы и тд.

У вас глаз еще не начал дергаться о этого праздника воинствующей упертости и невежества?

My soul is painted like the wings of butterflies (tm) %)

Я еще и петушню типа CQRS на джанге видел. Мож и про нее расскажешь что она нужна и нужно именно свой лисапет с дилдаком вместо сидения делать вместо использования GraphQL? И почему нужно именно DDD, а не TDD? И почему тебя не выгнали до сих пор, мне вот твое DDD не вперлось, а тому кто деньги платит и подавно срать, ему лишь бы сайт работал

CQRS … вместо использования GraphQL

А ты обратил внимание, что там queries отделены от mutations?

почему нужно именно DDD, а не TDD

Нужно и то, и другое. Не всегда и не всем, это да.

А вот карго-культизма и копипаста один-в-один без понемания, зачем и почему — однозначно следует избегать %) Хотя и учит, так сказать, семья и школа (тм).

почему тебя не выгнали до сих пор

Кто меня выгонит — я же кот.

А ты обратил внимание, что там queries отделены от mutations?

Я и написал ЧТО ЭТО И ЕСТЬ ТО САМОЕ CQRS

ЭТО И ЕСТЬ ТО САМОЕ CQRS

Так в чём проблема-то? Пользуйся на здоровье.

Линуксоиды, половина которых сидит на винде или в дуалбуте.

Как будто что-то плохое.

В том, что Java развращает молодежь, и они стараются писать на ней даже на Python

Java развращает молодежь

Экстремистское движение «джава-разработчики», азохнвей. Куды бечь. На петон даже не предлагай, там по одному логотипу всё понятно.

Да там, внезапно, свастика. Вполне себе узнаваема «по степени смешения». А бетонщики из индии уж очень любят её рисовать на видеоуроках. Ох, не с проста… А у Java Script вообще логотипа нет. Шах и мат.

это прекрасная астронавтика консультанта по технологиям

и есть специфика софта как почти полностью не материального изделия - возможность у интеграторов(софт-инженегроф) при слепке окончательного перьекта дифузировать раннее «взаимно независимые» детали реализации для выгребания последних процентов(а по факту порядков) производительности - либо буквально налагать на себя воздержание на себя от такого греха через использования 10x(и это не пределе) оборудования - что бы не сплавлять архитектуру софта

- вот такие копромисы

святая orm у Бугаенко

мирская orm и не орм вовсе ибо не достаточно абстрактна