Если писать на C/C++ правильно, то код не устареет, его достаточно будет пересобрать.
В этом плане JVM/.NET не сильно дальше от железа, чем Си:
вспомните истории, когда импорты системных функций делались с помощью Int32-, а не IntPtr-указателей, и как все посыпалось при переходе на x64-версии, особенно 8.1/10.
А все потому, что код был написан неправильно, и нужно было править именно исходники.
Также, вы не задумываись над таким вопросом?:
типы int (Integer, Int32), long (Long, Int64) в Java и .NET определены жестко:
32 и 64 бит.
При этом везде в коде, включая базовую библиотеку, используются именно 32-битные целые.
И все работает нормально только потому, что в x64 архитектуре 32-битное целое такое же "нативное", как и 64-битное.
И даже вследствие особенностей архитектуры более нативное: если не ошибаюсь, операции с 32-битными числами атомарные, а 64 — нет.
И что будет, когда появится действительно 64-битная архитектура? И тем более 128-битная? Где 32-битное целое будет эмулироваться, как сейчас это происходит с 8 и 16 бит.
Тогда здесь уместен ваш же аргумент против Java в части переписывания на Kotlin:
На C/C++ тоже практически все написано, и вряд ли все это будет переписываться на Rust.
Про Rust давно говорят (как говорили раньше про D), но где рабочие проекты, а если точнее, реальные вакансии?
На мой взгляд сейчас гораздо актуальнее новые нативные языки типа Go, Swift, Rust. Java нужна в-основном для допиливания давно написанного энтерпрайза, поэтому другие языки для JVM уже не взлетят — никто не будет переписывать софт
А можно поподробней?
Какую сферу применения вы видите для Rust?
Если позиционировать его как замену C++, то насколько знаю, C++ тоже используется в легаси кода — в финансовых приложениях, где важна скорость (поэтому C++, а не Java).
Какие есть еще области применения? Язык действительно очень интересный — системный и со всеми современными плюшками, хотелось бы его видеть в реальной работе.
Swift? Но если Swift, то почему вы не ставите на Kotlin? Для мобильной разработки он требуется в том же объеме, что и Swift (а когда выйдет Fuсhsia OS, писать/переписывыать приложения нужно будет еще больше).
Так что да, безусловно, я бы хотел увидеть написанным на джаве вообще всё, и работаю в этом направлении.
…
Это совершенно нормально — не связываться с излишней сложностью, когда с ней можно не связыватья. Введение дополнительного языка — это сложность. Использование Си позволяет избавиться от неё. В чем проблема?
Забавно.
Еще не так давно мир и двигался в этом направлении — некая централизация во всем:
Появились IDE вместо отдельных тестового редактора, компилятора и линковщика, и нам рассказывали, как это круто — делать все в одной IDE, причем в основном мышкой.
Один язык. Если очень упрощенно, конкурировали за эту роль C++ и Delphi/Object Pascal.
Затем — единая платформа/VM. Здесь будет уже ближе к действительности, если сказать, что конкурентами здесь были Java и .NET.
С другого ракурса — единые интегрированые системы управления жизненным циклом приложений. Вначале Borland ALM, потом Microsoft ALM (и TFS — лишь часть ее).
И вдруг что-то случилось.
Началось это примерно с бума планшетов (кстати, где они сейчас), и мифического закаты "эры ПК/буков" (вроде ужались до своей естественной ниши, а так живее всех живых).
Затем перекинулось почему-то на средства разработки.
Вновь стали отдельные компиляторы, редакторы, из IDE вынесена отдельно в невсегда работоспособные утилиты куча тулинга (а ведь до сих вроде нет такого же удобного мерджа, если не ошибаюсь, с семантическим анализом (?), как это было в TFS), и все это склеивалось на честном слове.
Снова разные языки (а уж какой вдораздел произошел между беком и фронтом, не описать).
И вновь разработка стала, как в 80-х — начале 90-х. Ну, почти.
И вдруг маятник качнулся в обратную сторону.
Тут и Web Assembly (можем писать на фронте на бек языках), а уж какой вклад в (ре)интеграцию внесли IDEA и Kotlin (разом под JVM, JS, Native)…
Ну и понятно, Node с JS/TS на бек-енде.
Т.е., все вновь стало стремиться к интеграции, и вновь появились конкурирующие экосистемы, предлагающие себя в качестве единой платформы.
Понятно, что это такой маятник развития.
Удивляет же реакция сообщества, как каждый раз подхватывается вот эта волна хайпа и забывается хорошее, что было сделано до, хотя можно было использовать много из старых наработок в новом качестве.
Пошел мятник назад — и история повторятся. И каждый раз забывается, что вот еще несколько лет назад на волне хайпа ратовали за противоположное.
По отношению к JS, это примерно как Kotlin (а также Lombok) для Java.
Кстати, есть Kotlin и для JS.
Также можно усмотреть аналогию «Kotlin теперь в списке официальных языков под Android, и на нем переписывается Spring» и «теперь Angular использует TS (вместо JS)».
Так что выпадение TS из статистики серьезно искажеает всю картину.
Отлично, что добавили в статью — описания этих ролей как раз не хватало.
Исходный комментарий связан с тем, что в некоторых окмпаниях и в понимании некоторых управленцев, сеньору приписываются навыки и полномочия лида.
Можно делализировать тот момент, что в сеньоры попадают как те, кто просто «заслуженный», и вроде на мидл-позицию его не поставишь, но сам разработчик и не хочет развиваться особо — так и те, кто мог бы стать архитектором и тех лидом, но, как вы заметили, что «архитекторы и тех лиды не нужны», поэтому они тоже идут в сеньоры, если не хотят идти в тим лиды и тем более в управленцы.
Хорошая статья, но опять типичная ошибка, когда путают сеньора и лида:
была должность аналогичная Синьору, называлась она Ведущий программист — такой специалист не просто много знает, но и еще ведет проекты или коллектив.
Раньше были старший и ведущий инженеры(-программисты).
Сейчас это называется Senior и Lead.
Нужно понимать, что это Lead ведет за собой, а Senior это такой заслуженный товарищ, которые много знает и умеет, решает сложные задачи, но работает в основном в одиночку.
А если и ведет/делится опытом, то больше на неформальном уровне.
Что касается лида — он может быть разный — Team Lead (ведущий конкретную команду с проектом), Tech Lead (ведущий в плане стратегического выбора технологий),
Так что написано очень хорошо, но одно это заставляет в целом усомниться, в полной ли мере ли автор точно понимает, о чем пишет в статье.
А чего стоит эта прибыль, если производители других товаров поступили так же (стали делать одноразовые ил/или некачественные товары, причем не при таким уж снижении цены)?
Получается, сколько бы нулей у твоей прибыли не было, это абстрактные цифры, которые ни во что хорошее не конвертируешь.
> Кому потом продавать стиралки ещё 20 лет?
Очень уж заезженный аргумент. Долго разбирать, но если кратко, то всегда есть кому продавать, особенно если уровень жизни растет или хотя бы не падает, да и моральное устаревание вещей и замена на новые всегда были и будут.
Плюс, никто не отменял как обычное перепрофилирование производства, так и вообще открытие новых рыночных/производственных ниш.
Да и в последнее время становится заметным экологический тренд — стимулирование сокращения использования пластиковых одноразовых пакетов и тары, сюда вполне вписывается и сокращение использования «одноразовых товаров».
> Про стандарты это правильно. Когда всплывает подобная тема, хочется задать вопрос: почему нельзя собраться всем лучшим дизайнерам, ученым, академикам и сделать раз и навсегда или на 20 лет удобную стиральную машину, или розетку электрическую или ложку. И клепать их, не тратить ресурсы впустую.
Так проходили уже, и видели эти «удобные» квадратно-гнездовые стиральные машины и ложки, и помним, чем закончилось.
Другое дело, что бывает, что в серию пошли действительно какие-то удобные, красивые, надежные и практичные вещи.
А потом вдруг либо пропадают из продажи, либо начинают выпускаться в варианте, удешевленном на порядок — причем на порядок удешевленных по качеству, а не по стоимости — а альтернативу, соответствующей прежнему качеству, зачастую не найти.
> Корень проблемы в том, что maxCharsPerByte() возвращает float
Тогда совсем печально.
Но позитив тут в том, что тут пример того, почему контракты библиотечных функций должны тщательно продумываться — ибо это влияет не только на продуктовый код, но на на другие библиотечные функции, и просто так это уже не вычистишь, пометив устаревшую функцию как deprecated.
Но это читерство, в реальном продуктовом и тем более библиотечном коде не должно быть:
«2000000000 не можем умножить на 3», т.к. в результате «String.getBytes() does not work on some strings larger than 16MB», давайте тогда приведем все это к double перед умножением.
Сорри, но это уровень студенческой лабораторной работы на тройку.
Уж лучше тогда использовать BigIngteger, хотя это оверхед, да и на момент выявления бага BigInteger в Java еще не было.
Если нужен был Workaround, то можно было б какой то свой Int128 (обертку над парой long) реализовать…
Во всяком случае, если посмотрим исходники JDK 8 по Unsigned-арифметике, там BigInteger вполне используется для борьбы с переполнением.
И наверняка можно было бы все решить проще и элегантнее — только не говорите, что надо было «быстро» — это ж библиотечная функция JDK, а не энтерпрайз-фичи по аджайлу и скраму.
Понадобился дробный множитель, и, естественно, для этого было выбран тип данных дробных чисел, а, точнее — тип данных с плавающей точкой?
Суть вопроса то в этом и заключается — зачем здесь дробный множитель, если есть в памяти строка из последовательности символов (UTF-16 или UTF-8 для java.lang.String? — кажется, первая), представленных целочисленными байтами, и нужно эти байты перекодировать так, чтобы они представляли ту же самую строку, но уже в другой кодировке?
Если, как тут пишут проблема в том, что (int)(double)(float)3 возвращает 0, то это, конечно, баг на каком то уровне — процессор или другой чип, драйвер, ОС, etc.
Однако, как уже отметили вопрос тут прежде всего по применимости float чисел к данной задаче.
Дело не в том, что float числа нужно сравнивать с применением epsilon, а в более фундаментальной вещи: зачем вообще в стандартной библиотеке делать реализацию метода, с использованием float, который работает с вещами, которые к float вообще не имеют отношения? Это похоже на хак с использованием каких-то особенностей float, который в редких кейсах приводит к неожиданным проблемам.
С float нужно работать только там, где входные и/или выходные данные float.
В .NET тоже есть похожие реализации с использованием float там, где можно обойтись целочисленными типами (DateTime, TimeSpan — внутри хранят количество тиков в long, часть операций реализована как сложение/вычитание long, а часть — через операции с double).
Если попытаться посмотреть детальнее, то окажется, что даже в рамках этого пути очень востребовано учиться учиться, кардинально менять деятельность, и т.д.:
Постоянно меняются и появляются новые технологии и подходы в разработки, в основном это «шум», но раз в несколько лет что-то из этого «выстреливает», и все достаточно кардинально меняется.
А поскольку современные технологии очень заточены на конкретные имплементации, то и чисто базовых CS-знаний тут не хватает, и нужно постоянно учиться и менять содержание своей деятельности.
В общем, вещи-то все известные, давайте посмотрим, как все менялось и в большом, и малом, и в разных разрезах:
Desktop -> Web -> Mobile Development
Desktop -> Remote Calling -> Web Back-End -> Cloud Computing / Clustering
Procedure Programming -> OOP -> Multiparadigmatic/Functional Programming
Это направления для примера, а так, они еще о переплетаются между собой, каждый из шагов опирается на новые языки и монструозные фреймворки, плюс для каждого шага можно фрактальным образом детализировать его содержимое, и т.д.
Например, сейчас многие разработчики Ruby/RoR переходит на Elixir/Erlang OTP/Phoenix — на первый взгляд, Phoenix это такой же MVC фреймворк, как RoR, но на деле и под капотом это означает смену парадигмы работы.
Или, те, кто когда то разрабатывал на Delphi, могли перейти на C# или Java — но для этого нужно было опять учиться и все сильно менять, особенно если ставить задачу писать в новой парадигме, а не «с Фортрана можно перейти на любой язык, и писать на нем, как на Фортране».
(Теперь совершить этот переход уже гораздо сложнее — для тех, кто уповал на былую востребованность.)
А сейчас вот, чтобы перейти на Kotlin, и не писать на нем, как на Java, нужно тоже приложить усилия.
На более длительных интервалах все еще сильнее меняется.
Я считаю, что чтобы понять, что такой код писать не надо, знание сложности необязательно.
Согласен с вами, есть куча таких моментов, которые проистекают из здравого смысла.
Что касается вопросов на "сложность", насколько понимаю, тому две причины:
Во-первых, можно усмотреть, что в разные периоды возникала разная мода на то, что спрашивать (зачастую такая мода необоснована с точки зрения сути предстоящей работы).
Во-вторых, применительно к .NET-сфере, насколько помню, такие вопросы стали возникать, когда появились дженерики и реализации типизированных Dictionary/SortedDictionary/SortedList (то того был только нетипизированный Hashtable и DictionaryBase, от которого наследовались узкоспециализированные коллекции), и когда затем появился LINQ.
Т.е., когда появились стандартные средства, предполагающие понимание сложности, тогда и появились вопросы.
О, обожаю эти вопросы про «какова сложность алгоритма»…
К реальной работе имеет отношение чуть больше чем никак
В который раз могу привести реальный пример из продуктового кода:
List<SomeType> list = GetSomeList();
foreach (var item in list)
{
int i = list.IndexOf(item);
// do something with item and i
}
Таки вы по-прежнему считаете, что сложность алгоритма не имеет отношения к реальности?
Понятно, что в реальной работе каждый день не программируется реализация графовых алгоритмов, но понимание таких вещей необходимо и при работе с базовыми типами данных, с которыми работа каждый день идет.
Так же, как понятно, и то, что достаточно вопросов на общее понимание этих вещей, и на то, чтобы понять, готов ли разработчик осознанно выбирать то, что ему подсказывает автозаполнение в IDE (в идеале — знакомиться с доками).
> опыт показывает, что если задача выходит за рамки применения стандартной библиотеки, то далеко не всегда можно нагуглить хоть что-то
Понимание базовых вещей нужно не только для того, чтобы сделать что-то, чего нет в стандартной библиотеке, а еще и для того, чтобы понимать, что для решения задачи нужно выбрать в стандартной и библиотеке, и как использовать.
Например, в приложении нужно сгенерировать случайную последовательность байтов.
В зависимости от задачи, нужно уточнить, что нам из стандартной библиотеки нужно использовать — генератор псевдослучайных чисел, или же задействовать генератор криптографически строгой последовательности (и то, и то, есть в современных платформах).
А в случае, если в задаче достаточно псевдослучайной последовательности, будет не лишним посмотреть в документации, обеспечивает ли конструктор по умолчанию генератора инициализацию seed хотя бы на основе текущего времени.
(А для этого ведь вообще нужно знать, что такое псевдослучайная последовательность.)
Т.е., даже если все, что нужно, есть в базовой библиотеке, нужно понимать, какие вообще типы задач существуют, и как они маппятся на стандартную библиотеку.
Конечно, в задаче генерации случайной последовательности редкая, но встречается.
Гораздо больше в проде можно встретить кода, который неумело работает с другими задачами, а где то вообще пишутся свои велосипеды, хотя в стандартной библиотеке (именно в библиотеке, а не сторонних «фреймворках») есть готовые решения.
И здесь нужно понимать, что такой код возникает не из-за незнания библиотеки, а из-за незнания именно классов задач.
Т.к. если бы было понимание, с задачей какого класса идет работа, то сразу бы возникло понимание, что нужно посмотреть, есть ли готовое решение (также понимание задачи позволяет понимать, где именно искать — в библиотке, фреймворках, учебниках или stackoverflow).
Вероятно, дело как раз в «явном озвучивании причины».
Почему это работает именно так (приводит к такому результату), прежде всего по психологическим причинам — долго объяснять, хотя на самом деле чуть выше один комментатор в трех строчках все объяснил.
Но можно посмотреть, как это работает с технологической точки зрения, и как улучшить результат.
По всей видимости, «в целом тянет своё направление» — это еще и орг работа (а, возможно, не орг, но тянет направление в «продуктовом» или «предметном»/доменном смысле)?
А нет версии, что на этом фоне, если идти на дауншифтинг, то чисто исполнительские скиллы, да еще в части применения современных технологий, ослабли?
Тогда есть смысл в собственном текущем развитии сконцентрироваться на подтягивании технологических знаний и навыков, и сделать в CV упор именно на эти навыки (наверняка уже все ушло вперед, и есть что наверстывать и/или переосмысливать в новом качестве), а организационные, руководящие, аналитические и тому подобные навыки задвинуть немного в фон.
А если при этом для перехода выбрать смежную, но технологически и политически более перспективную платформу, то желание перехода будет более понятно, и особо не придется ничего объяснять.
Другими словами, нужно не просто говорить «ах, мне это не нужно, а нужно то и то», и рассчитывать, что «то и то» тебе дадут, а нужно прежде всего внутренне измениться, и действительно хотеть и мочь пойти туда, где есть вот это «то и то».
Даже если сходу не получится попасть туда, куда 100% надо, то в середине пути человек обрастет и новыми знаниями, и новыми коллегами/знакомствами, вообще станет своим, и тогда конечная точка маршрута станет реально достижимой.
Да и не будет этой конечной точки — будет развитие на новом пути и и достижение все новых и новых вершин.
А при этом может еще и оказаться (и, скорее всего, окажется), что, сделав на новом пути дауншифтинг в занимаемой позиции, человек вырастет в материальном, в возможностях развития, в свободном времени, и т.д. — т.к. на новом пути в целом будет в целом «все лучше».
Но — все это требует огромной внутренней и не только внутренней работы («в свободное от основной работы время»!), и качественные результаты будут видны далеко не сразу — т.е., не тогда, когда человек выйдет на новую работу, а заметно после.
Почему только плюсовиков интересует, что будет от i++ + ++i
а в PHP, JS, Ruby и Java тонкости языка не выходят за пределы фриковских блогов?
Почему же?
В официальных экзаменах по Java достаточно подобных вопросов.
Да и в прод коде проектов на C# доводилось встречать подобное — кстати, по большей части от разрабов, которые не знают как следует язык.
К счастью, более новые языки (Swift, Kotlin) стараются избавляться от такого.
(Что касается Ruby, то мой личный опыт его изучения и опрос коллег, которые с ним работали, показывает, что там как раз имеет значение знание всех тонкостей — и этого, там, пожалуй, слишком много. Но на поверхностный взгляд может показаться, что там все просто.)
Если писать на C/C++ правильно, то код не устареет, его достаточно будет пересобрать.
В этом плане JVM/.NET не сильно дальше от железа, чем Си:
вспомните истории, когда импорты системных функций делались с помощью Int32-, а не IntPtr-указателей, и как все посыпалось при переходе на x64-версии, особенно 8.1/10.
А все потому, что код был написан неправильно, и нужно было править именно исходники.
Также, вы не задумываись над таким вопросом?:
типы int (Integer, Int32), long (Long, Int64) в Java и .NET определены жестко:
32 и 64 бит.
При этом везде в коде, включая базовую библиотеку, используются именно 32-битные целые.
И все работает нормально только потому, что в x64 архитектуре 32-битное целое такое же "нативное", как и 64-битное.
И даже вследствие особенностей архитектуры более нативное: если не ошибаюсь, операции с 32-битными числами атомарные, а 64 — нет.
И что будет, когда появится действительно 64-битная архитектура? И тем более 128-битная? Где 32-битное целое будет эмулироваться, как сейчас это происходит с 8 и 16 бит.
Тогда здесь уместен ваш же аргумент против Java в части переписывания на Kotlin:
На C/C++ тоже практически все написано, и вряд ли все это будет переписываться на Rust.
Про Rust давно говорят (как говорили раньше про D), но где рабочие проекты, а если точнее, реальные вакансии?
А Kotlin Native?
А можно поподробней?
Если позиционировать его как замену C++, то насколько знаю, C++ тоже используется в легаси кода — в финансовых приложениях, где важна скорость (поэтому C++, а не Java).
Какие есть еще области применения? Язык действительно очень интересный — системный и со всеми современными плюшками, хотелось бы его видеть в реальной работе.
Забавно.
Еще не так давно мир и двигался в этом направлении — некая централизация во всем:
И вдруг что-то случилось.
Началось это примерно с бума планшетов (кстати, где они сейчас), и мифического закаты "эры ПК/буков" (вроде ужались до своей естественной ниши, а так живее всех живых).
Затем перекинулось почему-то на средства разработки.
Вновь стали отдельные компиляторы, редакторы, из IDE вынесена отдельно в невсегда работоспособные утилиты куча тулинга (а ведь до сих вроде нет такого же удобного мерджа, если не ошибаюсь, с семантическим анализом (?), как это было в TFS), и все это склеивалось на честном слове.
Снова разные языки (а уж какой вдораздел произошел между беком и фронтом, не описать).
И вновь разработка стала, как в 80-х — начале 90-х. Ну, почти.
И вдруг маятник качнулся в обратную сторону.
Тут и Web Assembly (можем писать на фронте на бек языках), а уж какой вклад в (ре)интеграцию внесли IDEA и Kotlin (разом под JVM, JS, Native)…
Ну и понятно, Node с JS/TS на бек-енде.
Т.е., все вновь стало стремиться к интеграции, и вновь появились конкурирующие экосистемы, предлагающие себя в качестве единой платформы.
Понятно, что это такой маятник развития.
Удивляет же реакция сообщества, как каждый раз подхватывается вот эта волна хайпа и забывается хорошее, что было сделано до, хотя можно было использовать много из старых наработок в новом качестве.
Пошел мятник назад — и история повторятся. И каждый раз забывается, что вот еще несколько лет назад на волне хайпа ратовали за противоположное.
По отношению к JS, это примерно как Kotlin (а также Lombok) для Java.
Кстати, есть Kotlin и для JS.
Также можно усмотреть аналогию «Kotlin теперь в списке официальных языков под Android, и на нем переписывается Spring» и «теперь Angular использует TS (вместо JS)».
Так что выпадение TS из статистики серьезно искажеает всю картину.
Исходный комментарий связан с тем, что в некоторых окмпаниях и в понимании некоторых управленцев, сеньору приписываются навыки и полномочия лида.
Можно делализировать тот момент, что в сеньоры попадают как те, кто просто «заслуженный», и вроде на мидл-позицию его не поставишь, но сам разработчик и не хочет развиваться особо — так и те, кто мог бы стать архитектором и тех лидом, но, как вы заметили, что «архитекторы и тех лиды не нужны», поэтому они тоже идут в сеньоры, если не хотят идти в тим лиды и тем более в управленцы.
Хорошая статья, но опять типичная ошибка, когда путают сеньора и лида:
Раньше были старший и ведущий инженеры(-программисты).
Сейчас это называется Senior и Lead.
Нужно понимать, что это Lead ведет за собой, а Senior это такой заслуженный товарищ, которые много знает и умеет, решает сложные задачи, но работает в основном в одиночку.
А если и ведет/делится опытом, то больше на неформальном уровне.
Что касается лида — он может быть разный — Team Lead (ведущий конкретную команду с проектом), Tech Lead (ведущий в плане стратегического выбора технологий),
Так что написано очень хорошо, но одно это заставляет в целом усомниться, в полной ли мере ли автор точно понимает, о чем пишет в статье.
А чего стоит эта прибыль, если производители других товаров поступили так же (стали делать одноразовые ил/или некачественные товары, причем не при таким уж снижении цены)?
Получается, сколько бы нулей у твоей прибыли не было, это абстрактные цифры, которые ни во что хорошее не конвертируешь.
> Кому потом продавать стиралки ещё 20 лет?
Очень уж заезженный аргумент. Долго разбирать, но если кратко, то всегда есть кому продавать, особенно если уровень жизни растет или хотя бы не падает, да и моральное устаревание вещей и замена на новые всегда были и будут.
Плюс, никто не отменял как обычное перепрофилирование производства, так и вообще открытие новых рыночных/производственных ниш.
Да и в последнее время становится заметным экологический тренд — стимулирование сокращения использования пластиковых одноразовых пакетов и тары, сюда вполне вписывается и сокращение использования «одноразовых товаров».
Так проходили уже, и видели эти «удобные» квадратно-гнездовые стиральные машины и ложки, и помним, чем закончилось.
Другое дело, что бывает, что в серию пошли действительно какие-то удобные, красивые, надежные и практичные вещи.
А потом вдруг либо пропадают из продажи, либо начинают выпускаться в варианте, удешевленном на порядок — причем на порядок удешевленных по качеству, а не по стоимости — а альтернативу, соответствующей прежнему качеству, зачастую не найти.
Тогда совсем печально.
Но позитив тут в том, что тут пример того, почему контракты библиотечных функций должны тщательно продумываться — ибо это влияет не только на продуктовый код, но на на другие библиотечные функции, и просто так это уже не вычистишь, пометив устаревшую функцию как deprecated.
«2000000000 не можем умножить на 3», т.к. в результате «String.getBytes() does not work on some strings larger than 16MB», давайте тогда приведем все это к double перед умножением.
Сорри, но это уровень студенческой лабораторной работы на тройку.
Уж лучше тогда использовать BigIngteger, хотя это оверхед, да и на момент выявления бага BigInteger в Java еще не было.
Если нужен был Workaround, то можно было б какой то свой Int128 (обертку над парой long) реализовать…
Во всяком случае, если посмотрим исходники JDK 8 по Unsigned-арифметике, там BigInteger вполне используется для борьбы с переполнением.
И наверняка можно было бы все решить проще и элегантнее — только не говорите, что надо было «быстро» — это ж библиотечная функция JDK, а не энтерпрайз-фичи по аджайлу и скраму.
Понадобился дробный множитель, и, естественно, для этого было выбран тип данных дробных чисел, а, точнее — тип данных с плавающей точкой?
Суть вопроса то в этом и заключается — зачем здесь дробный множитель, если есть в памяти строка из последовательности символов (UTF-16 или UTF-8 для java.lang.String? — кажется, первая), представленных целочисленными байтами, и нужно эти байты перекодировать так, чтобы они представляли ту же самую строку, но уже в другой кодировке?
Если, как тут пишут проблема в том, что (int)(double)(float)3 возвращает 0, то это, конечно, баг на каком то уровне — процессор или другой чип, драйвер, ОС, etc.
Однако, как уже отметили вопрос тут прежде всего по применимости float чисел к данной задаче.
Дело не в том, что float числа нужно сравнивать с применением epsilon, а в более фундаментальной вещи: зачем вообще в стандартной библиотеке делать реализацию метода, с использованием float, который работает с вещами, которые к float вообще не имеют отношения? Это похоже на хак с использованием каких-то особенностей float, который в редких кейсах приводит к неожиданным проблемам.
С float нужно работать только там, где входные и/или выходные данные float.
В .NET тоже есть похожие реализации с использованием float там, где можно обойтись целочисленными типами (DateTime, TimeSpan — внутри хранят количество тиков в long, часть операций реализована как сложение/вычитание long, а часть — через операции с double).
Постоянно меняются и появляются новые технологии и подходы в разработки, в основном это «шум», но раз в несколько лет что-то из этого «выстреливает», и все достаточно кардинально меняется.
А поскольку современные технологии очень заточены на конкретные имплементации, то и чисто базовых CS-знаний тут не хватает, и нужно постоянно учиться и менять содержание своей деятельности.
В общем, вещи-то все известные, давайте посмотрим, как все менялось и в большом, и малом, и в разных разрезах:
Desktop -> Web -> Mobile Development
Desktop -> Remote Calling -> Web Back-End -> Cloud Computing / Clustering
Procedure Programming -> OOP -> Multiparadigmatic/Functional Programming
Это направления для примера, а так, они еще о переплетаются между собой, каждый из шагов опирается на новые языки и монструозные фреймворки, плюс для каждого шага можно фрактальным образом детализировать его содержимое, и т.д.
Например, сейчас многие разработчики Ruby/RoR переходит на Elixir/Erlang OTP/Phoenix — на первый взгляд, Phoenix это такой же MVC фреймворк, как RoR, но на деле и под капотом это означает смену парадигмы работы.
Или, те, кто когда то разрабатывал на Delphi, могли перейти на C# или Java — но для этого нужно было опять учиться и все сильно менять, особенно если ставить задачу писать в новой парадигме, а не «с Фортрана можно перейти на любой язык, и писать на нем, как на Фортране».
(Теперь совершить этот переход уже гораздо сложнее — для тех, кто уповал на былую востребованность.)
А сейчас вот, чтобы перейти на Kotlin, и не писать на нем, как на Java, нужно тоже приложить усилия.
На более длительных интервалах все еще сильнее меняется.
Согласен с вами, есть куча таких моментов, которые проистекают из здравого смысла.
Что касается вопросов на "сложность", насколько понимаю, тому две причины:
Т.е., когда появились стандартные средства, предполагающие понимание сложности, тогда и появились вопросы.
В который раз могу привести реальный пример из продуктового кода:
Таки вы по-прежнему считаете, что сложность алгоритма не имеет отношения к реальности?
Понятно, что в реальной работе каждый день не программируется реализация графовых алгоритмов, но понимание таких вещей необходимо и при работе с базовыми типами данных, с которыми работа каждый день идет.
Так же, как понятно, и то, что достаточно вопросов на общее понимание этих вещей, и на то, чтобы понять, готов ли разработчик осознанно выбирать то, что ему подсказывает автозаполнение в IDE (в идеале — знакомиться с доками).
Понимание базовых вещей нужно не только для того, чтобы сделать что-то, чего нет в стандартной библиотеке, а еще и для того, чтобы понимать, что для решения задачи нужно выбрать в стандартной и библиотеке, и как использовать.
Например, в приложении нужно сгенерировать случайную последовательность байтов.
В зависимости от задачи, нужно уточнить, что нам из стандартной библиотеки нужно использовать — генератор псевдослучайных чисел, или же задействовать генератор криптографически строгой последовательности (и то, и то, есть в современных платформах).
А в случае, если в задаче достаточно псевдослучайной последовательности, будет не лишним посмотреть в документации, обеспечивает ли конструктор по умолчанию генератора инициализацию seed хотя бы на основе текущего времени.
(А для этого ведь вообще нужно знать, что такое псевдослучайная последовательность.)
Т.е., даже если все, что нужно, есть в базовой библиотеке, нужно понимать, какие вообще типы задач существуют, и как они маппятся на стандартную библиотеку.
Конечно, в задаче генерации случайной последовательности редкая, но встречается.
Гораздо больше в проде можно встретить кода, который неумело работает с другими задачами, а где то вообще пишутся свои велосипеды, хотя в стандартной библиотеке (именно в библиотеке, а не сторонних «фреймворках») есть готовые решения.
И здесь нужно понимать, что такой код возникает не из-за незнания библиотеки, а из-за незнания именно классов задач.
Т.к. если бы было понимание, с задачей какого класса идет работа, то сразу бы возникло понимание, что нужно посмотреть, есть ли готовое решение (также понимание задачи позволяет понимать, где именно искать — в библиотке, фреймворках, учебниках или stackoverflow).
Почему это работает именно так (приводит к такому результату), прежде всего по психологическим причинам — долго объяснять, хотя на самом деле чуть выше один комментатор в трех строчках все объяснил.
Но можно посмотреть, как это работает с технологической точки зрения, и как улучшить результат.
По всей видимости, «в целом тянет своё направление» — это еще и орг работа (а, возможно, не орг, но тянет направление в «продуктовом» или «предметном»/доменном смысле)?
А нет версии, что на этом фоне, если идти на дауншифтинг, то чисто исполнительские скиллы, да еще в части применения современных технологий, ослабли?
Тогда есть смысл в собственном текущем развитии сконцентрироваться на подтягивании технологических знаний и навыков, и сделать в CV упор именно на эти навыки (наверняка уже все ушло вперед, и есть что наверстывать и/или переосмысливать в новом качестве), а организационные, руководящие, аналитические и тому подобные навыки задвинуть немного в фон.
А если при этом для перехода выбрать смежную, но технологически и политически более перспективную платформу, то желание перехода будет более понятно, и особо не придется ничего объяснять.
Другими словами, нужно не просто говорить «ах, мне это не нужно, а нужно то и то», и рассчитывать, что «то и то» тебе дадут, а нужно прежде всего внутренне измениться, и действительно хотеть и мочь пойти туда, где есть вот это «то и то».
Даже если сходу не получится попасть туда, куда 100% надо, то в середине пути человек обрастет и новыми знаниями, и новыми коллегами/знакомствами, вообще станет своим, и тогда конечная точка маршрута станет реально достижимой.
Да и не будет этой конечной точки — будет развитие на новом пути и и достижение все новых и новых вершин.
А при этом может еще и оказаться (и, скорее всего, окажется), что, сделав на новом пути дауншифтинг в занимаемой позиции, человек вырастет в материальном, в возможностях развития, в свободном времени, и т.д. — т.к. на новом пути в целом будет в целом «все лучше».
Но — все это требует огромной внутренней и не только внутренней работы («в свободное от основной работы время»!), и качественные результаты будут видны далеко не сразу — т.е., не тогда, когда человек выйдет на новую работу, а заметно после.
Почему же?
В официальных экзаменах по Java достаточно подобных вопросов.
Да и в прод коде проектов на C# доводилось встречать подобное — кстати, по большей части от разрабов, которые не знают как следует язык.
К счастью, более новые языки (Swift, Kotlin) стараются избавляться от такого.
(Что касается Ruby, то мой личный опыт его изучения и опрос коллег, которые с ним работали, показывает, что там как раз имеет значение знание всех тонкостей — и этого, там, пожалуй, слишком много. Но на поверхностный взгляд может показаться, что там все просто.)