Дожили. Разработчикам надо объяснять, что такое синус и косинус. Ещё скажите, что разработчики, которые работают с графикой, не знают, как работать с матрицами - а, ой...
Никакой это не эффект Манделы. Если вы внимательно посмотрите, в CS и сегодня широко используются МБ, КБ и так далее в своем оригинальном значении. Никаких ложных воспоминаний тут нет. Тождество 1 КБ = 1024 Б сильно старше самих единиц КиБ
На мой взгляд, использовать GSAP или даже WAAPI для таких простых вещей, как у вас в примере - то есть когда это можно заменить парой строк css - ужасный моветон
UPD. не обратил внимание, что это просто реклама сайта
Что вы подразумеваете под "хейтом"? Такими заявлениями вы понижаете уровень дискуссии. Нет, дело не в хейте. Вы привели как пример действительно одно очень интересное число. Да, нельзя утверждать на основании одного контрпримера, что метод нерабочий, но по-хорошему на вас, как на авторе, как раз лежит бремя показать, что он работает. А пока что есть одно "удобное" число и одно "неудобное". Убедительных доказательств работы кроме примера не представлено. Вот и все - это здоровый скептицизм и пространство для вас
От создателей "Парламент - не место для дискуссий". На мой взгляд, автор, отказавшись от обсуждения, статью полностью дискредитировал. Спасибо, что обратили внимание на число из статьи, действительно легко не заметить
Просто пришел какой-нибудь умник, начинавшийся про альтернативные подходы и решил все это внедрить. Мог бы и полоснуть (переписать на раст), как говорится
Автор же сразу оговорился, что не добавлял то, что есть в Java. В Java уже есть как sealed интерфейсы, так и Project Loom, полностью заменяющий корутины (понятно, что какой-нибудь андроид сидит на старых jdk, но это не меняет факта, что в языке это уже есть)
Ну, вообще это не аргумент). Извините за пример, но так-то люди веками тряпочками подтирались, а потом появилась туалетная бумага и приказ сверху "пользуйтесь ей, тряпочки Всё"
Я привык использовать ПМ для внешних свойств (как пример в статье), а полиморфизм для описания внутренних свойств. Так вот площадь является внутренним свойством объекта и считается специфично для каждой фигуры. Если вы спросили мое мнение - вот оно. Спорить не готов)
Имхо, "точно надо" неприменимо к опытным специалистам. Лично я стараюсь руководствоваться чисто здравым смыслом, не ставя четких рамок. Но как эталонный пример использования ПМ можно привести работу с sealed интерфейсами - туда это, на мой взгляд, вообще идеально вписывается
Наверное, я должен был явно сказать об основной претензии - вы подменяете понятия: смешиваете наличие конкретной языковой конструкции в ранней реализации ООП с сущностью парадигмы ООП. Отдельно есть парадигма, отдельно - ее реализации. А pattern matching этой парадигме ортогонален. Это может прозвучать так, будто я отстаиваю тезис, что pattern matching - отход от принципов ООП, но это такое же утрированное заявление, как ваше. Методологически верно и точно сказать, что это РАЗНЫЕ вещи.
Ну и раз вы используете слово "ортодоксальный", анекдотично отмечу, что наличие "inspect" не является догмой вроде "вот он, православный ООП".
Отдельно стоит пояснить, что я не спорю с идеей статьи и только рад последним изменениям в java, но настаиваю на ошибке в категоризации.
Возможно, надо раскрыть, почему я называю ПМ и ООП ортогональными понятиями?
Совсем недавно (по геологическим меркам) в джаваскрипте не было ключевого слова класс. Но ООП было, хоть и немного странное
Да, в этом и есть мой тезис). ООП - этой парадигма, switch с pattern-matching - по сути синтаксический сахар, class - ключевое слово, служащее реализации принципов ООП. Между этими тремя понятиями нет никакой иерархии (сlass keyword не является частью ООП, как и switch (не) является частью парадигмы).
А тут оказывается, что люди которые его создавали
Simula - это же не методичка и не спецификация ООП. Это один из первых языков, принципы ООП реализовавший. Точно так же, как
Ну и вот годами нам говорят, что решать обработку разнородных данных без полиморфизма это принципиальное нарушение ООП
...как и Страуструп не является источником истины об ООП (кстати, таких заявлений я сейчас не могу вспомнить, наверняка вы можете показать примеры?)
Еще раз хочу повториться: это ортогональные понятия. Чтобы придать веса моим словам, еще раз сошлюсь на теоретический базис - Expression Problem. К тому же, я в корне не согласен с вашим выводом о "возврате к ортодоксии". Java эволюционирует, а не возвращается к истокам. Понятно, что все новое - хорошо забытое старое, но вывод, который вы делаете, в том виде, в котором вы его делаете - максимально провокационный.
Вы распределили нагрузку между копиями одного и того же инстанса и объявили это микросервисной архитектурой...
Все эти задачи решаются powertoys :)
Гнать, гнать таких в шею...
"Итак" слитно ;)
Если вы пишете про котлин для тестирования, вам стоило бы показать, в чем котлин лучше для тестирования, а не что в нем есть var и val.
Дожили. Разработчикам надо объяснять, что такое синус и косинус. Ещё скажите, что разработчики, которые работают с графикой, не знают, как работать с матрицами - а, ой...
Никакой это не эффект Манделы. Если вы внимательно посмотрите, в CS и сегодня широко используются МБ, КБ и так далее в своем оригинальном значении. Никаких ложных воспоминаний тут нет. Тождество 1 КБ = 1024 Б сильно старше самих единиц КиБ
На мой взгляд, использовать GSAP или даже WAAPI для таких простых вещей, как у вас в примере - то есть когда это можно заменить парой строк css - ужасный моветон
UPD. не обратил внимание, что это просто реклама сайта
Что вы подразумеваете под "хейтом"? Такими заявлениями вы понижаете уровень дискуссии. Нет, дело не в хейте. Вы привели как пример действительно одно очень интересное число. Да, нельзя утверждать на основании одного контрпримера, что метод нерабочий, но по-хорошему на вас, как на авторе, как раз лежит бремя показать, что он работает. А пока что есть одно "удобное" число и одно "неудобное". Убедительных доказательств работы кроме примера не представлено. Вот и все - это здоровый скептицизм и пространство для вас
От создателей "Парламент - не место для дискуссий". На мой взгляд, автор, отказавшись от обсуждения, статью полностью дискредитировал. Спасибо, что обратили внимание на число из статьи, действительно легко не заметить
Просто пришел какой-нибудь умник, начинавшийся про альтернативные подходы и решил все это внедрить. Мог бы и полоснуть (переписать на раст), как говорится
Давно пора hr заменить на кого-то более компетентного, например gpt5
Очень смело, конечно, заявлять, что переопределение операторов повышает читаемость кода :)
Автор же сразу оговорился, что не добавлял то, что есть в Java. В Java уже есть как sealed интерфейсы, так и Project Loom, полностью заменяющий корутины (понятно, что какой-нибудь андроид сидит на старых jdk, но это не меняет факта, что в языке это уже есть)
Ну, вообще это не аргумент). Извините за пример, но так-то люди веками тряпочками подтирались, а потом появилась туалетная бумага и приказ сверху "пользуйтесь ей, тряпочки Всё"
Я привык использовать ПМ для внешних свойств (как пример в статье), а полиморфизм для описания внутренних свойств. Так вот площадь является внутренним свойством объекта и считается специфично для каждой фигуры. Если вы спросили мое мнение - вот оно. Спорить не готов)
Shape, Circle и Rectangle)
Имхо, "точно надо" неприменимо к опытным специалистам. Лично я стараюсь руководствоваться чисто здравым смыслом, не ставя четких рамок. Но как эталонный пример использования ПМ можно привести работу с sealed интерфейсами - туда это, на мой взгляд, вообще идеально вписывается
Наверное, я должен был явно сказать об основной претензии - вы подменяете понятия: смешиваете наличие конкретной языковой конструкции в ранней реализации ООП с сущностью парадигмы ООП. Отдельно есть парадигма, отдельно - ее реализации. А pattern matching этой парадигме ортогонален. Это может прозвучать так, будто я отстаиваю тезис, что pattern matching - отход от принципов ООП, но это такое же утрированное заявление, как ваше. Методологически верно и точно сказать, что это РАЗНЫЕ вещи.
Ну и раз вы используете слово "ортодоксальный", анекдотично отмечу, что наличие "inspect" не является догмой вроде "вот он, православный ООП".
Отдельно стоит пояснить, что я не спорю с идеей статьи и только рад последним изменениям в java, но настаиваю на ошибке в категоризации.
Возможно, надо раскрыть, почему я называю ПМ и ООП ортогональными понятиями?
Да, в этом и есть мой тезис). ООП - этой парадигма, switch с pattern-matching - по сути синтаксический сахар, class - ключевое слово, служащее реализации принципов ООП. Между этими тремя понятиями нет никакой иерархии (сlass keyword не является частью ООП, как и switch (не) является частью парадигмы).
Simula - это же не методичка и не спецификация ООП. Это один из первых языков, принципы ООП реализовавший. Точно так же, как
...как и Страуструп не является источником истины об ООП (кстати, таких заявлений я сейчас не могу вспомнить, наверняка вы можете показать примеры?)
Еще раз хочу повториться: это ортогональные понятия. Чтобы придать веса моим словам, еще раз сошлюсь на теоретический базис - Expression Problem. К тому же, я в корне не согласен с вашим выводом о "возврате к ортодоксии". Java эволюционирует, а не возвращается к истокам. Понятно, что все новое - хорошо забытое старое, но вывод, который вы делаете, в том виде, в котором вы его делаете - максимально провокационный.