но в целом Я-музыка научилась таки подбирать то, что более/менее подходит под стили и предпочтения "моей волны"
Уже разучилась, причем несколько лет назад. Пришли очередные эффективные манагеры и угробили неплохую систему рекомендаций (вплоть до полного выпиливания), потом подбор похожих исполнителей, а добили все в итоге редизайном. Причем на столько все испохабили, что спустя десяток лет пришлось вернуться к аимпу.
Спасибо, но нет. Порочность этой практики прекрасно иллюстрирует виндовая проблема MAX_PATH. Проблема не актуальна уже лет 20 как и фактически почила вместе с добровольно-принудительным переездом дисков с FAT на NTFS, но до сих пор периодически ставит палки в колеса. Зачем? Непонятно, потому что даже версии софта, которым это было актуально, тихо утонули в недрах интернета.
Это не говоря о взгляде со стороны бизнеса, когда на поддержку подобного тратиться уйма времени с нулевой генерацией как прибыли, так и репутации.
А уж когда в руки попадает легаси с 10+ летней историей, на 70% заваленный фактически неиспользуемым кодом (ну а вдруг понадобится), все становится вообще печально. Плюшкинизм среди разработчиков - привет проблемам в долгой перспективе, особенно когда состав раза 2-3 полностью успел смениться и никто в этой археологии уже ни в зуб ногой.
Это плоховато сочетается с концентрацией ответственности, но в общем-то даже и так перебрать всё в цикле обычно не составит труда.
С концентрацией ответственности все впорядке, просто привет от наркоманской геометрии с тригонометрией. И цикл не вариант, а то каждый билд будет собираться сутки.
Для этого надо заранее знать, из какого в какой тип придётся преобразовывать.
А вы как хотели? Волшебной кнопки "Сделать красиво" не существует. Что в сях десяток принтов был и хаки форматирования, что наркомания с перегрузкой операторов для cin/cout, а в решетке и жаве "магические" наследуемые методы ToString для каждого типа. Конвертация - это тоже та еще проблема. Если в лоб конвертнуть сингл (float) 0.5 в дабл, то на конце появится хвост через много нулей. А bool в число так вообще чем угодно может обернуться.
Маловероятный частный случай – что эти корявые данные будут отличаться от некорявых типом.
И чем только не отличаются, когда человек берет в свои руки клавиатуру. Везде, где в деле замешаны люди, может случиться, и случается, все, что угодно. Причем порой на столько тупые ошибки, что аж удивление берет.
На мой взгляд, это не банальная операция, а антипаттерн проектирования. Не надо так делать вообще никогда.
Вы в сферическом вакууме живете, где бизнес, оборудование и библиотеки не меняются веками? Каждый мажорный релиз библиотек ломает обратную совместимость. Даже между версиями одного языка порой полная несовместимость. Фреймворки - та же история, даже .NET сломал обратную совместимость с появлением Core, что уж про всякие ангулары, цэфы и прочих говорить. Бизнес, о дитя непостоянства, там структуры данных меняются по чиху кого угодно, от руководства всех звеньев, до чиновников, и по нескольку раз в год. А может устройства постоянные? Ага, как же. То одну железку навесят, то другую снимут, то четвертую вместо третьей подцепят, со словами - назад уже не веремся, и, неожиданно, так и не возвращаются. И это не какой-то там ниокр (который и сам несколько лет может занять), это уже развитие существующего.
Хранить все старье, ради мифической полной обратной совместимости? Стоимость такой поддержки того не стоит, а потому все придерживаются практики ограниченной поддержки "вот вам N месяцев на обновление, а дальше ваша проблема".
Развитие любого продукта без breaking changes невозможно, потому что меняются технологии, меняются средства, меняется сам мир. А вы говорите - антипаттерн и никогда. Понятное дело, что не каждый день такое, но и не сказать что прям совсем редко это случается, что бы частным случаем обозвать. Минимум пару раз в год приходится сталкиваться, что обновление ломает обратную совместимость, а порой и самому приходится делать тоже самое, потому что дальше поддерживать мертвый хвост уже слишком дорого и не стоит того.
Я вот лично здесь пришёл бы к необходимости параметрического полиморфизма.
Как козу не обзывай, а набор поддерживаемых типов остается один и тот же. Причем фиксированный и статический, буквально, захардкоженный. И как не крути, а этот самый "параметрический полиморфизм" намного проще сделать на языках со статической типизацией, а особенно на сях, всего лишь объявив пару перегрузок.
Проблему-то надо решать в принципе, а не в маловероятном частном случае.
Корявые входные данные, особенно подготовленные человеками в виде файлов - это ни разу не маловероятный частный случай.
У меня большой опыт использования как статически, так и динамически типизированных языков (в основном даже статически), и я не припоминаю, чтобы статическая типизация уровня Алгола/Паскаля/C++ мне реально особо помогала бороться с ошибками, вопреки провозглашаемым лозунгам.
Похоже опыт у нас был разный. Мой на динамически типизируемых языках был прямо противоположным. От кучи заложенных мин по наследству, до прямых трудноуловимых багов, которые на сях и решетках допустить просто невозможно.
Банальные опечатки, поиски по всем файлам формата требуемой структуры данных, поиск по коду какие вообще данные там должны храниться (привет от Size, который может быть и целое число, и дробное число, и струкрура, а в особо упоротых случаях вообще размерность), особенно если имена не говорящие, прекрасная отладка, когда все вроде ВЫГЛЯДИТ нормально, но не работает (потому что опечатка, ошибка в имени, использвоание полей, которых уже нет, тип данных неправильный, подчеркнуть нужное). И не дай бог это сторонний код, да еще и обфусцированный в придачу.
Да даже банальная операция удаления свойства из структуры в языках со статической типизацией потянет за собой ошибки компиляции по всем местам, где оно используется. И сколько такой грязи тянется при обновлении сторонних библиотек, не перечесть. Более того, даже если документация есть (что далеко не всегда), не все изменения между версиями описывают, зачастую обходясь парой куцых строчек с обобщенным описанием. Что лучше, получить все эти проблемы сразу, на этапе компиляции, или молиться, что тесты покрывают абсолютно все пограничники и оно никогда не выстрелит?
Сколько раз выручал контроль за типами со стороны компилятора, просто не перечесть.
Но если у вас в программе существуют участки путей исполнения, не покрытые тестами (хотя бы синтетическими), то это косяк, который никакая статическая типизация не исправит.
Ага, пока не возникает метод с 10^4 сочетаний пограничных случаев. Реальный случай, кстати.
в котором нет никаких проблем передать строку на место числового параметра или умножить их (получив ошибку в рантайме)
Неявные преобразования с нарушением принципа симметричности - это зло.
И вот мы пришли к прикручиванию системы статической типизации для параметров, но через костыли и велосипеды, ибо поддержки этого нет.
Результатом будет вызов doesNotUnderstand или что там в конкретном языке.
В JS вполне себе будет NaN, без всяких ошибок. А потом этот NaN пойдет по цепочке, если не обвязывать его тонной бойлерплейта. И все из-за отсутствия статической типизации, которая четко говорит: принимаю только числа, пошел нафиг, с новым годом.
А если понадобилась еще и строка, то добавь отдельный метод/кусок кода, который ее проверит, распарсит и передаст в исходный метод число.
Изначально в смолтоке объекту можно было посылать любое сообщение, не заботясь о том, понимает он его или нет. В C++ и происходящих от него языках вызов несуществующего метода не скомпилируется.
И это прекрасно, что падает. Только не говорите, что никогда в жизни не делали опечатки. Потому что найти опечатку глазами среди тонны кода - это то еще приключение. А если оно еще и в рантайме не падает, то хорошо, если придется страдать самому.
И спустя пару месяцев даже самостоятельно такое попробуй поймай, а если это достанется по наследству, то вообще хавайся в бульбу. Перелопатить сотни-тысячи строчек в поисках опечатки, то еще удовольствие.
Сколько не пробовал эксплорером пользоваться, даже в комплекте с PowerToys, закончилось все установкой дабла на рабочую машину. По десятку вкладок на каждую колонку и по запущенной копии на каждый монитор, для особо замороченных случаев. Плюс превью с быстрым переключением формата/кодировок, плюс быстрое редактирование в блокноте в одну кнопку. Без всех этих мелочей довольно неудобно уже пользоваться.
Дома тотал, даже купленный уже давно как.
А вот с фаром совсем не дружу. В свое время синюшный моник ноута сильно глаза под убил, больше не могу нормально читать его сине-белую гамму.
Ага, чему там будет равно 8000 * "С новым годом, Малыш", при вычисления оборотов? Вполне себе валидное выражение, с точки зрения JS, и даже вычисляется без ошибки.
Более того, Карлсон в ходе своей жизни или даже своего полёта может научиться отвечать на поздравления с новым годом.
Да любой тип обычно принимает.
После того, как его неоднократно отскребут от асфальта из-за NaN оборотов. И хорошо, если он на асфальт упадет, а не на мимопроходила в длинной шапке.
Статическую? Совсем нет.
Да любой тип обычно принимает.
% оборотов пропеллера не может быть строкой, булевкой, объектом и прочими. Это дробное число, в которое могут быть явно и неявно преобразованы только целые цисла или дробные числа меньшей точности. А если будут неявно конвертироваться дробные числа большей точности, то мы теряем дробный хвост, который с каждым арифметическим действием все больше и больше будет увеличивать погрешность, приводя к фейс об вол.
Я считаю, это вообще была самая полезная идея ООП (утраченная в C++ и его производных).
А в каком месте она была утрачена? Программа не может работать с абсолютно произвольными данными. И даже в языках с динамической типизацией не может, пока не описано что с ними делать в каждом конкретном случае.
С динамическими типами можно просто поправить шаблон в рантайме
Я это и со статической типизацией легко могу сделать, вот прямо вообще никаких проблем. И, простите, с этим "правленным" шаблоном, что бы "кривые" данные ошибки не били, вы что потом делать будете?
У вас летит Карлсон, а ему вместо процента оборотов пропеллера прилетела строка "С новым годом, Малыш". Повлияет ли это на работоспособность программы полета к банке варенья? Потому что для обработки этой ошибки нужно криво-косо, но прикрутить ту самую типизацию, которой из коробки нет.
А потом приходят Малыши и собирают своих Карлсонов v. X.Y.Z.B, постоянно наступая на одни и те же грабли, не зная какой тип принимает ваш метод управления пропеллером.
А усугубляется все это, когда входящие типы расширяются до объектов, особенно когда сам язык позволяет динамически создавать поля у объектов, создавая идеальный простор для трудно отлаживаемых выстрелов в ногу (о великий JS, стрелой в колено стражника попадающий).
Динамическая типизация, конечно, не всегда зло. Есть ограниченный ряд случаев, когда она помогает существенно упростить код (привет нативные либы и врапперы над ними). Но в большинстве остальных случаев она приводит или к оверинженирингу, или к требованию иметь идеальную память, или к трудно-уловимым багам из-за очепяток, которые при строгой типизации ловятся еще на этапе компиляции.
Очень маловероятно, чтобы в реальной программе ошибка возникла бы именно на уровне несовместимости int с bool.
Вот только недавно правил эти ошибки на парсинге данных в динамически сформированные структуры, со строгой типизацией полей. Пусть уже не компилятор, но рантайм активно ругался и кидался экскрементами на каждый чих. И bool в int, и float в double, и float в int, строки во все что только можно, и даже int в enum с различными ошибками внезапно вылез. И каждая критична, то double хвост подхватил, то в данные пытается залезть непойми что, потому что ошиблись с нумерацией, то значения изначально кривые сами по себе, то ошибки описания самих структур данных. Человеческий фактор он такой.
Да даже с обычным парсером без жесткой типизации никуда, потому что всегда пытаются подсунуть какую-нибудь грязь, а тебе это надо поймать, залогировать, а в идеальном случае еще и носом ткнуть, где косяк допустили.
Лови потом последствия с динамическими типами, когда через месяц все неожиданно посыпется в на проде, получив булевку вместо высоты условной летающей фанеры над Парижем и температуры штанов колобота. Особенно, если это не тот случай, когда можно отмазаться фразой "у нас все работает".
Ну, формально конечно можно обмазать все проверками типов в методах, ноооо... это ведь и есть введение строгой типизации через костыли и велосипеды.
Если 2 системы (или куска) общаются, то однажды обязательно рассинхрон возникнет, и хорошо, если это будет не ПО управления лучем марсианскиго тренога или, самый страшный кошмар, система проведения платежей в пятерочке высосет все бабки, получив условный NaN.
А уж легаси читать и править, не имея структуры данных в пределах пары кнопок, это вообще то еще веселье по заучиванию over 9000 структур, что бы не путаться между ними и ничего не сломать. Привет монструозные поделки на голом JS, где очепятку в присвоении параметра можно ловить часами, а то и днями (незабываемый опыт).
Всякие TypeScript и Ко не от хорошей жизни придумали.
Статус демонстрировать не перед кем. Понты или в другой области, или интровертам пофиг на них. Остается только прослойка с очень сильными хотелками. Остальные выбирают машину в соответствии со своими потребностями, и всякие ламбо-порше по ним далеко не в лидерах.
По опыту моих лосей (AOC) скажу, что при использовании любого пресета практически все настройки блокируются, за исключением разгона, вставки черных кадров и т.п. Что бы настроить руками под себя, нужно переключить моники в кастом пресет и включить ручную настройку цвета (USERRGB), и только тогда можно будет подогнать все настройки руками.
Причем блокируется настройка как из меню монитора, так и из винды и даже из их софта для настроек.
Его отключают уже не во время атак, а просто 24/7 отключили. И не только интернет, но просто мобильная связь через одно место работает, то звонки сбоят, то смски не отправляются.
Платить за «появляешься в офисе 160 часов в месяц» более применимо к сервисной сфере, где надо либо с клиентами постоянно взаимодействовать "с 9 до 18", либо автобус там какой водить.
Вполне себе обычная практика, когда заключается договор на консультационные услуги на N часов в месяц. Есть работа, нет работы, заплатите за N часов. Даже в офисе зачастую появляться не нужно. Ситуация как с бэкапами, может и не понадобятся, но когда понадобятся, хорошо иметь под рукой.
1. По идее, наёмный ИПшник тоже должен выполнять любую прихоть? За этим его и нанимают, или я не так понял?
Есть 2 "вида" договора:
1. Классический аутсорс, когда продается результат, в договоре описывается что именно сделать, к какой дате, за фиксированную сумму, по хорошему с детальным ТЗ в приложении. Любой каприз - это долгая процедура с согласованием допсоглашений, переносом сроков и т.д. и т.п. И расторгнуть основной договор - это то еще приключение, потому что согласование сторон.
2. Классический аутстаф, ака наемники, когда продается время, договор оформляется рамочный с указанием часовой ставки, с расторжением по почесу левой пятки, а выполненные работы оформляются актами. Именно в актах указываются недостающие данные, которые дополняют договор до полного, в соответствии с законодательством. Хочет заказчик тоже самое, но с перламутровыми пуговицами? Да пожалуйста, получите в конце периода акт на перламутровые пуговицы, у вас 5 дней на претензию, а иначе акт считается подписанным.
Аутсорт очень любит юный мелкий бизнес, правда при этом они сами не знают чего хотят. Потом они считают себя умными, заключают аутстаф, вылазят за пределы бюджета и начинается фарс, дубль 2.
На месте ИП есть опции подумать
Иметь своего/юлизкого/знакомого адвоката/юриста - это полезно далеко не только ИП и ООО. А лучшая защита от судов - это грамотно составленный договор, для которого опять таки нужен "свой" юрист, что бы дал по шее еще до подписания.
Десктоп, дотнет, впф, 15 лет. Стабильно осенью-зимой минимум десяток предложений в линкдине, от удаленки до релокации. Когда недавно пришлось сменить работу в срочном порядке, 5 откликов - собес - оффер, на все про все чуть больше недели.
Когда сам собесил людей пару лет назад, так там такое "море" приходило, что все ну очень печально было. И это до нас уже пена долетала, после первичного отсева.
У мажоров была минимум 5600, а чаще уже 6 серия или чуть более поздние поделия красных с глючавым каталистом.
У плебеев в то время была уже 5200, а на ней по умолчанию графика была желтушная, сильно замыленная и пересвеченная. Тут и закос под старую или дешевую кинопленку, и начало эпохи блюра с глумом, и попытка спрятать низкую детализацию мира за сглаживанием, которое в итоге превращало картинку в мыло-мыльное. После андеграундов оно выглядело довольно отвратительно и приходилось очень сильно играть с настройками, что бы привести картинку во что-то более-менее вменяемое.
Тем более, пью антидепрессанты, хоть и не от депрессии, но тоже прописали.
3-4 часа я ещё могу из себя выжимать. 5 — в редкие дни.
У меня последние полгода потребность в сне 12-16 часов в сутки
А не на антидепрессанты ли банальная побочка? Меня на эту гадость когда посадили, я на третью смену колес их просто выкинул. Дикая постоянная сонливость, ватный мозг и тошнота в комплекте, все ровно по разделу побочек в инструкции и работать совершенно не возможно.
В данном случае ближе будет аналогия с бейсбольной битой на постсоветском пространстве. Да, есть отдельные владельцы, которые играют в бейсбол, но большинство покупают для использования совсем не по назначению. ))
Аналогично и с множественным наследованием классов, да есть определенный процент тех, кто действительно понимает как и зачем его использует. Проблема в остальных, которые уже 4 десятка лет используют его в основном для выстрелов в ногу.
Причем, эта жесткая нелюбовь к множественному наследованию передается уже много поколений плюсовиков, т.к. зачастую само множественное наследование происходит из-за изначально переусложненной архитектуры, слишком сильно перегруженной абстракциями ради абстракций.
Уже разучилась, причем несколько лет назад. Пришли очередные эффективные манагеры и угробили неплохую систему рекомендаций (вплоть до полного выпиливания), потом подбор похожих исполнителей, а добили все в итоге редизайном. Причем на столько все испохабили, что спустя десяток лет пришлось вернуться к аимпу.
Спасибо, но нет. Порочность этой практики прекрасно иллюстрирует виндовая проблема MAX_PATH. Проблема не актуальна уже лет 20 как и фактически почила вместе с добровольно-принудительным переездом дисков с FAT на NTFS, но до сих пор периодически ставит палки в колеса. Зачем? Непонятно, потому что даже версии софта, которым это было актуально, тихо утонули в недрах интернета.
Это не говоря о взгляде со стороны бизнеса, когда на поддержку подобного тратиться уйма времени с нулевой генерацией как прибыли, так и репутации.
А уж когда в руки попадает легаси с 10+ летней историей, на 70% заваленный фактически неиспользуемым кодом (ну а вдруг понадобится), все становится вообще печально. Плюшкинизм среди разработчиков - привет проблемам в долгой перспективе, особенно когда состав раза 2-3 полностью успел смениться и никто в этой археологии уже ни в зуб ногой.
С концентрацией ответственности все впорядке, просто привет от наркоманской геометрии с тригонометрией. И цикл не вариант, а то каждый билд будет собираться сутки.
А вы как хотели? Волшебной кнопки "Сделать красиво" не существует. Что в сях десяток принтов был и хаки форматирования, что наркомания с перегрузкой операторов для cin/cout, а в решетке и жаве "магические" наследуемые методы ToString для каждого типа. Конвертация - это тоже та еще проблема. Если в лоб конвертнуть сингл (float) 0.5 в дабл, то на конце появится хвост через много нулей. А bool в число так вообще чем угодно может обернуться.
И чем только не отличаются, когда человек берет в свои руки клавиатуру. Везде, где в деле замешаны люди, может случиться, и случается, все, что угодно. Причем порой на столько тупые ошибки, что аж удивление берет.
Вы в сферическом вакууме живете, где бизнес, оборудование и библиотеки не меняются веками? Каждый мажорный релиз библиотек ломает обратную совместимость. Даже между версиями одного языка порой полная несовместимость. Фреймворки - та же история, даже .NET сломал обратную совместимость с появлением Core, что уж про всякие ангулары, цэфы и прочих говорить. Бизнес, о дитя непостоянства, там структуры данных меняются по чиху кого угодно, от руководства всех звеньев, до чиновников, и по нескольку раз в год. А может устройства постоянные? Ага, как же. То одну железку навесят, то другую снимут, то четвертую вместо третьей подцепят, со словами - назад уже не веремся, и, неожиданно, так и не возвращаются. И это не какой-то там ниокр (который и сам несколько лет может занять), это уже развитие существующего.
Хранить все старье, ради мифической полной обратной совместимости? Стоимость такой поддержки того не стоит, а потому все придерживаются практики ограниченной поддержки "вот вам N месяцев на обновление, а дальше ваша проблема".
Развитие любого продукта без breaking changes невозможно, потому что меняются технологии, меняются средства, меняется сам мир. А вы говорите - антипаттерн и никогда. Понятное дело, что не каждый день такое, но и не сказать что прям совсем редко это случается, что бы частным случаем обозвать. Минимум пару раз в год приходится сталкиваться, что обновление ломает обратную совместимость, а порой и самому приходится делать тоже самое, потому что дальше поддерживать мертвый хвост уже слишком дорого и не стоит того.
Как козу не обзывай, а набор поддерживаемых типов остается один и тот же. Причем фиксированный и статический, буквально, захардкоженный. И как не крути, а этот самый "параметрический полиморфизм" намного проще сделать на языках со статической типизацией, а особенно на сях, всего лишь объявив пару перегрузок.
Корявые входные данные, особенно подготовленные человеками в виде файлов - это ни разу не маловероятный частный случай.
Похоже опыт у нас был разный. Мой на динамически типизируемых языках был прямо противоположным. От кучи заложенных мин по наследству, до прямых трудноуловимых багов, которые на сях и решетках допустить просто невозможно.
Банальные опечатки, поиски по всем файлам формата требуемой структуры данных, поиск по коду какие вообще данные там должны храниться (привет от Size, который может быть и целое число, и дробное число, и струкрура, а в особо упоротых случаях вообще размерность), особенно если имена не говорящие, прекрасная отладка, когда все вроде ВЫГЛЯДИТ нормально, но не работает (потому что опечатка, ошибка в имени, использвоание полей, которых уже нет, тип данных неправильный, подчеркнуть нужное). И не дай бог это сторонний код, да еще и обфусцированный в придачу.
Да даже банальная операция удаления свойства из структуры в языках со статической типизацией потянет за собой ошибки компиляции по всем местам, где оно используется. И сколько такой грязи тянется при обновлении сторонних библиотек, не перечесть. Более того, даже если документация есть (что далеко не всегда), не все изменения между версиями описывают, зачастую обходясь парой куцых строчек с обобщенным описанием. Что лучше, получить все эти проблемы сразу, на этапе компиляции, или молиться, что тесты покрывают абсолютно все пограничники и оно никогда не выстрелит?
Сколько раз выручал контроль за типами со стороны компилятора, просто не перечесть.
Ага, пока не возникает метод с 10^4 сочетаний пограничных случаев. Реальный случай, кстати.
Неявные преобразования с нарушением принципа симметричности - это зло.
И вот мы пришли к прикручиванию системы статической типизации для параметров, но через костыли и велосипеды, ибо поддержки этого нет.
В JS вполне себе будет NaN, без всяких ошибок. А потом этот NaN пойдет по цепочке, если не обвязывать его тонной бойлерплейта. И все из-за отсутствия статической типизации, которая четко говорит: принимаю только числа, пошел нафиг, с новым годом.
А если понадобилась еще и строка, то добавь отдельный метод/кусок кода, который ее проверит, распарсит и передаст в исходный метод число.
И это прекрасно, что падает. Только не говорите, что никогда в жизни не делали опечатки. Потому что найти опечатку глазами среди тонны кода - это то еще приключение. А если оно еще и в рантайме не падает, то хорошо, если придется страдать самому.
И спустя пару месяцев даже самостоятельно такое попробуй поймай, а если это достанется по наследству, то вообще хавайся в бульбу. Перелопатить сотни-тысячи строчек в поисках опечатки, то еще удовольствие.
Сколько не пробовал эксплорером пользоваться, даже в комплекте с PowerToys, закончилось все установкой дабла на рабочую машину. По десятку вкладок на каждую колонку и по запущенной копии на каждый монитор, для особо замороченных случаев. Плюс превью с быстрым переключением формата/кодировок, плюс быстрое редактирование в блокноте в одну кнопку. Без всех этих мелочей довольно неудобно уже пользоваться.
Дома тотал, даже купленный уже давно как.
А вот с фаром совсем не дружу. В свое время синюшный моник ноута сильно глаза под убил, больше не могу нормально читать его сине-белую гамму.
Ага, чему там будет равно 8000 * "С новым годом, Малыш", при вычисления оборотов? Вполне себе валидное выражение, с точки зрения JS, и даже вычисляется без ошибки.
После того, как его неоднократно отскребут от асфальта из-за NaN оборотов. И хорошо, если он на асфальт упадет, а не на мимопроходила в длинной шапке.
% оборотов пропеллера не может быть строкой, булевкой, объектом и прочими. Это дробное число, в которое могут быть явно и неявно преобразованы только целые цисла или дробные числа меньшей точности. А если будут неявно конвертироваться дробные числа большей точности, то мы теряем дробный хвост, который с каждым арифметическим действием все больше и больше будет увеличивать погрешность, приводя к фейс об вол.
А в каком месте она была утрачена? Программа не может работать с абсолютно произвольными данными. И даже в языках с динамической типизацией не может, пока не описано что с ними делать в каждом конкретном случае.
Я это и со статической типизацией легко могу сделать, вот прямо вообще никаких проблем. И, простите, с этим "правленным" шаблоном, что бы "кривые" данные ошибки не били, вы что потом делать будете?
У вас летит Карлсон, а ему вместо процента оборотов пропеллера прилетела строка "С новым годом, Малыш". Повлияет ли это на работоспособность программы полета к банке варенья? Потому что для обработки этой ошибки нужно криво-косо, но прикрутить ту самую типизацию, которой из коробки нет.
А потом приходят Малыши и собирают своих Карлсонов v. X.Y.Z.B, постоянно наступая на одни и те же грабли, не зная какой тип принимает ваш метод управления пропеллером.
А усугубляется все это, когда входящие типы расширяются до объектов, особенно когда сам язык позволяет динамически создавать поля у объектов, создавая идеальный простор для трудно отлаживаемых выстрелов в ногу (о великий JS, стрелой в колено стражника попадающий).
Динамическая типизация, конечно, не всегда зло. Есть ограниченный ряд случаев, когда она помогает существенно упростить код (привет нативные либы и врапперы над ними). Но в большинстве остальных случаев она приводит или к оверинженирингу, или к требованию иметь идеальную память, или к трудно-уловимым багам из-за очепяток, которые при строгой типизации ловятся еще на этапе компиляции.
Вот только недавно правил эти ошибки на парсинге данных в динамически сформированные структуры, со строгой типизацией полей. Пусть уже не компилятор, но рантайм активно ругался и кидался экскрементами на каждый чих. И bool в int, и float в double, и float в int, строки во все что только можно, и даже int в enum с различными ошибками внезапно вылез. И каждая критична, то double хвост подхватил, то в данные пытается залезть непойми что, потому что ошиблись с нумерацией, то значения изначально кривые сами по себе, то ошибки описания самих структур данных. Человеческий фактор он такой.
Да даже с обычным парсером без жесткой типизации никуда, потому что всегда пытаются подсунуть какую-нибудь грязь, а тебе это надо поймать, залогировать, а в идеальном случае еще и носом ткнуть, где косяк допустили.
Лови потом последствия с динамическими типами, когда через месяц все неожиданно посыпется в на проде, получив булевку вместо высоты условной летающей фанеры над Парижем и температуры штанов колобота. Особенно, если это не тот случай, когда можно отмазаться фразой "у нас все работает".
Ну, формально конечно можно обмазать все проверками типов в методах, ноооо... это ведь и есть введение строгой типизации через костыли и велосипеды.
Если 2 системы (или куска) общаются, то однажды обязательно рассинхрон возникнет, и хорошо, если это будет не ПО управления лучем марсианскиго тренога или, самый страшный кошмар, система проведения платежей в пятерочке высосет все бабки, получив условный NaN.
А уж легаси читать и править, не имея структуры данных в пределах пары кнопок, это вообще то еще веселье по заучиванию over 9000 структур, что бы не путаться между ними и ничего не сломать. Привет монструозные поделки на голом JS, где очепятку в присвоении параметра можно ловить часами, а то и днями (незабываемый опыт).
Всякие TypeScript и Ко не от хорошей жизни придумали.
"Норм" машины - это:
Демонстрация статуса
Понты
Хочу
Статус демонстрировать не перед кем. Понты или в другой области, или интровертам пофиг на них. Остается только прослойка с очень сильными хотелками. Остальные выбирают машину в соответствии со своими потребностями, и всякие ламбо-порше по ним далеко не в лидерах.
По опыту моих лосей (AOC) скажу, что при использовании любого пресета практически все настройки блокируются, за исключением разгона, вставки черных кадров и т.п. Что бы настроить руками под себя, нужно переключить моники в кастом пресет и включить ручную настройку цвета (USERRGB), и только тогда можно будет подогнать все настройки руками.
Причем блокируется настройка как из меню монитора, так и из винды и даже из их софта для настроек.
У жены на ее лыжах (LG) все аналогично.
Так Wurm Online же, 2006 год. Задолго не только до викингов с каннибалами, но и до кубических шахтеров.
Его отключают уже не во время атак, а просто 24/7 отключили. И не только интернет, но просто мобильная связь через одно место работает, то звонки сбоят, то смски не отправляются.
Вполне себе обычная практика, когда заключается договор на консультационные услуги на N часов в месяц. Есть работа, нет работы, заплатите за N часов. Даже в офисе зачастую появляться не нужно. Ситуация как с бэкапами, может и не понадобятся, но когда понадобятся, хорошо иметь под рукой.
Есть 2 "вида" договора:
1. Классический аутсорс, когда продается результат, в договоре описывается что именно сделать, к какой дате, за фиксированную сумму, по хорошему с детальным ТЗ в приложении. Любой каприз - это долгая процедура с согласованием допсоглашений, переносом сроков и т.д. и т.п. И расторгнуть основной договор - это то еще приключение, потому что согласование сторон.
2. Классический аутстаф, ака наемники, когда продается время, договор оформляется рамочный с указанием часовой ставки, с расторжением по почесу левой пятки, а выполненные работы оформляются актами. Именно в актах указываются недостающие данные, которые дополняют договор до полного, в соответствии с законодательством. Хочет заказчик тоже самое, но с перламутровыми пуговицами? Да пожалуйста, получите в конце периода акт на перламутровые пуговицы, у вас 5 дней на претензию, а иначе акт считается подписанным.
Аутсорт очень любит юный мелкий бизнес, правда при этом они сами не знают чего хотят. Потом они считают себя умными, заключают аутстаф, вылазят за пределы бюджета и начинается фарс, дубль 2.
Иметь своего/юлизкого/знакомого адвоката/юриста - это полезно далеко не только ИП и ООО. А лучшая защита от судов - это грамотно составленный договор, для которого опять таки нужен "свой" юрист, что бы дал по шее еще до подписания.
Десктоп, дотнет, впф, 15 лет. Стабильно осенью-зимой минимум десяток предложений в линкдине, от удаленки до релокации. Когда недавно пришлось сменить работу в срочном порядке, 5 откликов - собес - оффер, на все про все чуть больше недели.
Когда сам собесил людей пару лет назад, так там такое "море" приходило, что все ну очень печально было. И это до нас уже пена долетала, после первичного отсева.
У мажоров была минимум 5600, а чаще уже 6 серия или чуть более поздние поделия красных с глючавым каталистом.
У плебеев в то время была уже 5200, а на ней по умолчанию графика была желтушная, сильно замыленная и пересвеченная. Тут и закос под старую или дешевую кинопленку, и начало эпохи блюра с глумом, и попытка спрятать низкую детализацию мира за сглаживанием, которое в итоге превращало картинку в мыло-мыльное. После андеграундов оно выглядело довольно отвратительно и приходилось очень сильно играть с настройками, что бы привести картинку во что-то более-менее вменяемое.
А не на антидепрессанты ли банальная побочка? Меня на эту гадость когда посадили, я на третью смену колес их просто выкинул. Дикая постоянная сонливость, ватный мозг и тошнота в комплекте, все ровно по разделу побочек в инструкции и работать совершенно не возможно.
Как миниум еще найтвиз и ускорялка для комфортных забегов.
В данном случае ближе будет аналогия с бейсбольной битой на постсоветском пространстве. Да, есть отдельные владельцы, которые играют в бейсбол, но большинство покупают для использования совсем не по назначению. ))
Аналогично и с множественным наследованием классов, да есть определенный процент тех, кто действительно понимает как и зачем его использует. Проблема в остальных, которые уже 4 десятка лет используют его в основном для выстрелов в ногу.
Причем, эта жесткая нелюбовь к множественному наследованию передается уже много поколений плюсовиков, т.к. зачастую само множественное наследование происходит из-за изначально переусложненной архитектуры, слишком сильно перегруженной абстракциями ради абстракций.