Ну для ознакомления прошло уже достаточно времени, и да, читать код стало сложнее, если var используется где-то за пределами for(var entry : map.entrySet()), т.к. при чтении кода (по крайней мере мне) проще сканить глазами типы, написанные первым словом в строке, понимая сразу все накладываемые на переменную ограничения и особенности поведения, чем надеяться, что автор кода придумал идеальное имя переменной, такое, что при быстром сканировании кода оно не будет вызывать вопросов и вводить в заблуждение.
При этом существует вполне нормальная официальная рекомендация по использованию var, и если бы ей все следовали, всё было бы вполне неплохо. Но в большинстве своих фич, java сопротивляется "плохим" решениям разработчиков (но они конечно всё равно находят способы с этим справитьс, а тут способствует.
Под хорошо/плохо я в частности имею ввиду локальность контекста: в идеальном коде для понимания локального участка кода необходимо минимально осмотреться вокруг, пару строк вверх пару строк вниз. То, что ближе к этому - хорошо, то что дальше - плохо.
А по моему опыту и с локальными кусками так себе выходит. Но мне помогает гуглить "то не знаю что", в т.ч. образцами кода, которые я в 95% случаев полностью переписываю в итоге (хотя иногда у меня таки поднимается бровь, когда оно что-то вменяемое действительно генерит).
Ещё у меня коллега мой код ревьюит в т.ч. с помощью chat gpt. И я вам скажу, выходит неожиданно круто.
Сегодня уже можно опустить и класс, и main, и вообще написать этот пример в одну строку)
Естественно, в реальной жизни, никто этого делать не будет. Ровно как и сравнивать когнитивную нагрузку по строкам кода, а не по семантически значимым конструкциям.
Динамическая типизация не обязательно супер-проблема, если есть мощный JIT. Как в Java, например)
JIT отслеживает какие типы реально приходят в участок кода, чаще всего из-за того, что в реальности тип всегда один и тот же, получается поставить относительно дешёвые trap'ы на входе в большой кусок кода для верификации типов и в дальнейшем работать с полным его пониманием.
Мне пока не так уж близко до 40, хотя и опыта более чем достаточно. Но я никогда не запилю свой стартап. Это просто другой навык, не инженерный. Я не умею продавать, особенно продавать сырое. Не умею планировать крупные финансовые вложения. Не умею нанимать специалистов, чьи компетенции не пересекаются с моими. Не умею исследовать рынок. И так далее. Я умею быть инженером, умею это хорошо, люблю эту работу и хочу этим заниматься. А не (свои) стартапы пилить)
Не уверен, что в вышеперечисленных конторах действительно фильтруют по возрасту, в т.ч. потому что там работает достаточно много старых пердунов) и именно с ними всегда работалось наиболее комфортно. Сейчас меня окружает значительно более молодой контингент, и очень не хватает трезвого взгляда людей, которые уже десять раз видели как один хайповый фреймворк меняется другим и становится легаси, делая полный круг.
Сложный код пишут не потому что книжек перечитали, а потому что сложный код написать просто, а простой сложно. Именно чтобы писать простой код нужен опыт, причем не тот, что в годах измеряется, а скорее тот, что измеряется вырванными волосами и удачей с коллегами, способными научить своим примером.
В первом примере, как я и сказал, единственная неожиданность может быть вызвана наличием кэша, потому что новичок мог бы ожидать, что будет всегда false.
Во втором случае всё совсем полностью понятно: сравнение ссылочного типа с примитивным принципиально невозможно, значит должен быть анбоксинг.
Замечу, что первый пример в реальной жизни я встречал 0 раз за 20 лет. Второй примерно 1.5 раза.
Я вас не понимаю. Моим ожиданиям сравнение в java полностью соответствует. Можете пожалуйста привести один-два конкретных примера кода, где оно не соответствует вашим?
Простите, что вы имеете ввиду? В Java "ссылочные типы" всегда сравниваются по значению. Возможно вы про эффекты наличия объектов в Constant Pool? Или про кэши Integer? Это ничего не меняет, это всё ещё равенство ссылок.
В JVM внутри по возможности используются сжатые указатели (если адресуемая память позволяет и сборщик мусора не утилизирует дополнительные биты указателей для "раскраски"). Почитать можно тут: https://wiki.openjdk.org/display/HotSpot/CompressedOops
Производительность от этого чаще растёт, т.к. большу́ю часть времени JVM занимает перекладывание байтиков. Меньше указателей - меньше байтиков перекладывать.
Секундочку, надо ещё после умножения /деления сделать | 0 или что-то аналогичное, чтобы получить целочисленный результат. Ну и погреть надо ~10к раз перед тем как время мерить, чтобы JIT точно сработал.
Ещё бы желательно время мерить через performance.now, но для такого расхождения это не так критично.
Забыл, что мы о дробях. Да, показательно. Я бы конечно убедился, что умножение таки дробное, но думаю, всё сойдется таким же образом.
Upd2. Нет, всё-таки надо погреть. И всё-таки надо воткнуть / 10.0. На всякий случай)
Деление и умножение дробей отличаться по производительности не должны бы. Но вот первую конструкцию V8 почти наверняка развернет в целочисленное умножение. Вторую уже совсем не факт.
Когда я брал было хуже) если уволился - верни деньги. Целиком. И рефинансирование было невозможно, т.к. было выдано через НКО, а такое банки, на тот момент по крайней мере, не рефинансировали.
Занимал у друзей, продавал квартиру, отдавал. Но в сухом остатке, за вычетом нервов, всё равно вышло достаточно выгодно.
По эффекту: да. Но путь совсем другой. Точнее первые десять лет потратили на то, чтобы сделать как в С#. К счастью, в результате поняли, что сова в процессе натяжения на глобус может лопнуть и сделали всё совсем с другой стороны.
Я не понял, о каком "неудачном типе" вы говорите, кажется, в моем комментарии такое выражение не встречается.
Ну для ознакомления прошло уже достаточно времени, и да, читать код стало сложнее, если var используется где-то за пределами for(var entry : map.entrySet()), т.к. при чтении кода (по крайней мере мне) проще сканить глазами типы, написанные первым словом в строке, понимая сразу все накладываемые на переменную ограничения и особенности поведения, чем надеяться, что автор кода придумал идеальное имя переменной, такое, что при быстром сканировании кода оно не будет вызывать вопросов и вводить в заблуждение.
При этом существует вполне нормальная официальная рекомендация по использованию var, и если бы ей все следовали, всё было бы вполне неплохо. Но в большинстве своих фич, java сопротивляется "плохим" решениям разработчиков (но они конечно всё равно находят способы с этим справитьс, а тут способствует.
Под хорошо/плохо я в частности имею ввиду локальность контекста: в идеальном коде для понимания локального участка кода необходимо минимально осмотреться вокруг, пару строк вверх пару строк вниз. То, что ближе к этому - хорошо, то что дальше - плохо.
А по моему опыту и с локальными кусками так себе выходит. Но мне помогает гуглить "то не знаю что", в т.ч. образцами кода, которые я в 95% случаев полностью переписываю в итоге (хотя иногда у меня таки поднимается бровь, когда оно что-то вменяемое действительно генерит).
Ещё у меня коллега мой код ревьюит в т.ч. с помощью chat gpt. И я вам скажу, выходит неожиданно круто.
Сегодня уже можно опустить и класс, и main, и вообще написать этот пример в одну строку)
Естественно, в реальной жизни, никто этого делать не будет. Ровно как и сравнивать когнитивную нагрузку по строкам кода, а не по семантически значимым конструкциям.
Динамическая типизация не обязательно супер-проблема, если есть мощный JIT. Как в Java, например)
JIT отслеживает какие типы реально приходят в участок кода, чаще всего из-за того, что в реальности тип всегда один и тот же, получается поставить относительно дешёвые trap'ы на входе в большой кусок кода для верификации типов и в дальнейшем работать с полным его пониманием.
Грубо, но надо сказать, частично справедливо. Кажется, публичность - часть профессии, как и построение социальных связей.
Мне пока не так уж близко до 40, хотя и опыта более чем достаточно. Но я никогда не запилю свой стартап. Это просто другой навык, не инженерный. Я не умею продавать, особенно продавать сырое. Не умею планировать крупные финансовые вложения. Не умею нанимать специалистов, чьи компетенции не пересекаются с моими. Не умею исследовать рынок. И так далее. Я умею быть инженером, умею это хорошо, люблю эту работу и хочу этим заниматься. А не (свои) стартапы пилить)
Нет, если кто-то говорит "у всех так", то аргумент "у меня не так" действительно важный, валидный и понятный.
Не уверен, что в вышеперечисленных конторах действительно фильтруют по возрасту, в т.ч. потому что там работает достаточно много старых пердунов) и именно с ними всегда работалось наиболее комфортно. Сейчас меня окружает значительно более молодой контингент, и очень не хватает трезвого взгляда людей, которые уже десять раз видели как один хайповый фреймворк меняется другим и становится легаси, делая полный круг.
Сложный код пишут не потому что книжек перечитали, а потому что сложный код написать просто, а простой сложно. Именно чтобы писать простой код нужен опыт, причем не тот, что в годах измеряется, а скорее тот, что измеряется вырванными волосами и удачей с коллегами, способными научить своим примером.
В первом примере, как я и сказал, единственная неожиданность может быть вызвана наличием кэша, потому что новичок мог бы ожидать, что будет всегда false.
Во втором случае всё совсем полностью понятно: сравнение ссылочного типа с примитивным принципиально невозможно, значит должен быть анбоксинг.
Замечу, что первый пример в реальной жизни я встречал 0 раз за 20 лет. Второй примерно 1.5 раза.
Я вас не понимаю. Моим ожиданиям сравнение в java полностью соответствует. Можете пожалуйста привести один-два конкретных примера кода, где оно не соответствует вашим?
Простите, что вы имеете ввиду? В Java "ссылочные типы" всегда сравниваются по значению. Возможно вы про эффекты наличия объектов в Constant Pool? Или про кэши Integer? Это ничего не меняет, это всё ещё равенство ссылок.
В JVM внутри по возможности используются сжатые указатели (если адресуемая память позволяет и сборщик мусора не утилизирует дополнительные биты указателей для "раскраски"). Почитать можно тут: https://wiki.openjdk.org/display/HotSpot/CompressedOops
Производительность от этого чаще растёт, т.к. большу́ю часть времени JVM занимает перекладывание байтиков. Меньше указателей - меньше байтиков перекладывать.
Секундочку, надо ещё после умножения /деления сделать | 0 или что-то аналогичное, чтобы получить целочисленный результат. Ну и погреть надо ~10к раз перед тем как время мерить, чтобы JIT точно сработал.Ещё бы желательно время мерить через performance.now, но для такого расхождения это не так критично.Забыл, что мы о дробях. Да, показательно. Я бы конечно убедился, что умножение таки дробное, но думаю, всё сойдется таким же образом.
Upd2. Нет, всё-таки надо погреть. И всё-таки надо воткнуть / 10.0. На всякий случай)
"Встроенный в Intellij IDEA профайлер" - это async-profiler.
Деление и умножение дробей отличаться по производительности не должны бы. Но вот первую конструкцию V8 почти наверняка развернет в целочисленное умножение. Вторую уже совсем не факт.
Когда я брал было хуже) если уволился - верни деньги. Целиком. И рефинансирование было невозможно, т.к. было выдано через НКО, а такое банки, на тот момент по крайней мере, не рефинансировали.
Занимал у друзей, продавал квартиру, отдавал. Но в сухом остатке, за вычетом нервов, всё равно вышло достаточно выгодно.
Не похоже. Судя по всему, это перевод доклада. Чтобы ощутить весь масштаб катастрофы, придется опуститься в пучину почтовых рассылок)
По эффекту: да. Но путь совсем другой. Точнее первые десять лет потратили на то, чтобы сделать как в С#. К счастью, в результате поняли, что сова в процессе натяжения на глобус может лопнуть и сделали всё совсем с другой стороны.