Pull to refresh
4
0.2
Send message

Я отвечал в контексте всей ветки комментов.

Всё не так просто.

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

  2. Корпорации - это всегда люди. И простые сотрудники, и топ-менеджеры, и владельцы. А люди - пипец какие сложные. И стремление быть хорошим и создавать что-то хорошим - такие же части человеческой природы, как и стремление к наживе.

Любая подмена реальности каким-либо ярлыком или стереотипом - это всё равно заблуждение.

Если один стереотип нелеп и абсурден, то из этого совершенно не следует, что противоположный ему верен.

Или многочисленные истории про то, как люди оскорбляются тем, что YandexGPT как-то не так отвечает на определённые вопросы. Любые, абсолютно любые отклонения ответов от их ожиданий, люди готовы объяснить, что Яндекс продался западу, и встроил в свой ИИ враждебную идеологию.

Тут даже Медведев отметился:

https://t.me/medvedev_telegram/496

А ещё после этой истории появились люди, которые начали писать, что этот эпизод показывает, что Яндекс всё-таки могут выключить алгоритм!

А значит, всё это время, когда Яндекс объяснял алгоритмом увеличение цен в дождь, это на самом деле была не правда! Оказывается, Яндекс все эти годы мог выключить алгоритм, и начать возить всех за свой счёт! И они этого не делали просто потому что, не хотели!

Это всегда так.

В сети есть определённе субкультуры, которые верят, что Яндекс/Сбер/Озон/Ктотоещё - по умолчанию контора нехороших людей, и абсолютно любую новость про эти компании толкуют в свете этого. И, конечно же, абсолютно всё, что делают эти компании - часть коварного плана.

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

А когда через два часа Яндекс таки в этом районе обнулил цены, начал за свой счёт нагонять машины в этот район и вернул деньги всем, кто до этого уехал из этого района, ЭТИ ЖЕ люди начали кричать, что это уже совсем за гранью добра и зла, мерзкий Яндекс делает себе пиар на крови!

>> Как по мне, так префикс is совершенно не нужен. Например Active это уже само по себе прилагательное,

Это хорошо работает только до тех пор, когда слово очевидно является именно прилагательным.

Но в английском языке полно слов, которые могут быть и прилагательным, и глаголом. И вот тут как раз начинаются проблемы.

Некоторое время назад на хабре упоминалась история про багу, которая получилась, когда программист вызвал у контейнера метод .empty(), ожидая, что это очистит содержимое контейнера. Но на самом деле этот метод просто возвращал bool, который показывает - пуст контейнер или нет.

Так что я всячески поддерживаю соглашение о том, что такие методы должны начинаться в "is".

Проблема только в том, что равенство выполняется только для bounty = 0.

Соответственно, получается бесконечная фабрика ничего.

В Москве - шаурмист, в Питере - шавермейстер.

>> за необоснованный ООП

За необоснованное что угодно можно бить по рукам.

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

Я не знаю, что у вас за специфичный проект такой был.

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

Ну и расстановка типов не увеличивает как-то драматически ни объём кода, ни затраченное время на его написание.Уж точно не в разы, даже если сказать, что на 10% - то это достаточно пессимистичная оценка.

del, не туда ответил

Вы когда-нибудь занимались поддержкой проекта на 100000+ строк, в который два десятка программистов несколько лет писали?

Я бы посмотрел, как вы это будете без типов делать.

>> в бестиповом языке

Вот только в питоне строгая типизация.

>> То, что Python криво задизайнили

А в чём именно вы видите кривой дизайн? В том, что в питоне нельзя по ошибке применить конкатенацию вместо сложения?

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

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

>> И я говорю о проблеме в целом (об исследовании Ларри), а не о Python конкретно.

О какой проблеме-то? Во многих языках (включая питон) нет проблемы с неоднозначностью сложения/конкатенации, а польза от типов - есть.

И типы, внезапно, нужны не только для того, чтобы сделать счастливым компилятор. А ещё и для того, чтобы сделать работу программиста проще и сократить число ошибок.

И, кстати, почему вы упорно называете Ларри Уолла только по имени? Вы с ним лично знакомы?

В питоне под аннотациями понимают вполне конкретную вещь. В статье речь именно про питоновские аннотации.

Ну, логично, что аннотации не вырезаются.

Ведь они являются полноценным атрибутом, и программист вполне может завязать какую-то логику на проверку аннотаций функции. Было бы странно, если бы оптимизация ломала такую логику.

>> а сконкатенировать?

А что вы вообще подразумеваете под конкатенацией строки и числа применительно к питону? И чем это отличается от сложения строки и числа?

В питоне для датаклассов обычно не используются какие-то отдельные функции конструкторы. А само по себе инстанцирование датакласса занимает примерно столько же места, сколько и создание словаря.

Information

Rating
3,087-th
Registered
Activity