var dayName = switch (day) {
case 1 -> "Понедельник";
case 2 -> "Вторник";
case 3 -> "Среда";
case 4 -> "Четверг";
case 5 -> "Пятница";
case 6 -> "Суббота";
case 7 -> "Воскресенье";
default -> "Неверный день";
};
Прочитал статью и так и не понял кто заставляет автора писать в джаве аннотации вместо кода.
проверяемые исключения вас компилятор заставит обработать (если не гасить их, разумеется). А в го нужно весь код обмазывать проверками ? Лучше бы тогда сделали монаду either.
NPE можно поймать в 2 случаях: ты джун и возвращаешь из методов null-ы или ты используешь чужую либу, в которой такой возврат не задокументирован.
Пишу с SE 1го поколения, который 6s в корпусе 5s. Приложения работают нормально, Хабр вот читаю. Ничего не тупит. Обновления до сих пор еще бывают, в основном безопасности. Apple Music до сих пор слушаю с него.
Одно расстраивает - аккум стал совсем плох. Приходится таскать постоянно пауэр банк еще.
Предположите, что есть некоторое дублирование намеренийcase J -> press J, и поэтому эти вот case Smth можно спрятать за некоторой абстракцией, и эти абстракции будут как некоторые контейнеры, в которые вы сложили вашу чистую логику press1...pressN
Поэтому замените типовое выражение match key { case Smth:
Когда уже есть некоторое понимание, то это кажется логичным и правильным и сами абстракции нет смысла держать в голове, остается только думать над смыслом, который хочешь выразить. Абстракции просто клей между частями головоломки
Поддержу автора, мне понравилось как надстройка над хаскелем, но еще выше уровнем.
не вижу проблем с чтением этого кода.
Обработка нажатий клавиатуры:
j - перемещение вниз
K - перемещение вниз
и т.д.
Возможно, есть шероховатости, но общая концепция понятна - отделить инструмент от бизнес-логики, что на самом деле, действительно, является проблемой разработки . Инструмент (ЯП) переплетен с предметной областью настолько, что разработчикам очень сложно выразить ясно свои намерения под тоннами абстракций, которые они пишут. Автор пытается эти абстракции как раз спрятать за спец символами, оставив чистую логику.
Не вижу проблем с изучением, как и любой язык. А абстракции на то и абстракции, чтобы один раз понять как они работают и потом не возвращаться к этому, оставив себе в качестве работы решение проблем бизнеса - конкретных задач, а не очередную борьбу выразить на очередном языке свои намерения.
на самом деле это просто низкая инженерная культура. На java можно писать нормально, если не делать всё со всем связанным и всё подряд со скоупом public.
Все становится гораздо прозрачнее, если строить взаимодействие между пакетами только через интерфейсы и забыть про публичные классы
// создание DI контейнераfinal TinyDI notDI = new TinyDI();// инициализация - указываем все классы являющиеся зависимостямиnotDI.setup(List.of(Users.class,Sessions.class,LocaleStorage.class, BookRecordStorage.class,RestAPI.class,Expression.class, Json.class,PageHandler.class,ResourceHandler.class));
По-моему вы просто реализовали свой контейнер IoC, а не DI. Не проще было использовать синглтоны с фабричными методами и не городить огород с контейнерами ?
Кмк идти по пути решения проблемы отладки, это как на паровоз прикручивать навороченные сенсоры отслеживания давления пара, чтобы понимать почему котлы взрываются. Вместо перехода на электродвигатели.
Как в свое время перешли с перфокарт, а затем с ассемблерного кода, так и сейчас пора перестать решать задачи компьютера человеком и перейти уже на языки еще более высокого уровня для решения прикладных задач, вместо решения проблем связки программист-машина.
А вот на мой взгляд, для разработчиков, умение лаконично и грамотно выразить свои мысли текстовым сообщением, гораздо важнее, чем трепаться по телефону. Это отнимает на порядок меньше времени, позволяет зафиксировать договоренности и имеет эффект отложенного анализа текста.
В конце концов, если вы текстом деньги зарабатываете, то нужно уметь его писать.
Кмк эта проблема слегка надумана и уйдет после того, как перестанут использоваться указатели напрямую и произойдет переход на функциональную парадигму (неизменяемые данные, объекты и т.п.)
List<?> twice = s.addAll(s); // просто сделает удвоение существующего списка при вызове метода.
Неизменяемые поля в джава с ключевым словом final. Без - изменяемые по-умолчанию.
Только у final более широкое применение, не только для полей классов.
Я не понимаю про именования каких бинов идёт речь. Рекорды не являются бинами.
Java:
Java:
record Person(String name, int age) {}Расскажите всем, кто пишет на котлин, что 8я джава вышла 11 лет назад
В 2025м году стоит сравнивать хотя бы с 21й версией джавы. И тут окажется, что преимущества котлина не так очевидны (а то и вообще отсутствуют).
Прочитал статью и так и не понял кто заставляет автора писать в джаве аннотации вместо кода.
проверяемые исключения вас компилятор заставит обработать (если не гасить их, разумеется). А в го нужно весь код обмазывать проверками ? Лучше бы тогда сделали монаду either.
NPE можно поймать в 2 случаях: ты джун и возвращаешь из методов null-ы или ты используешь чужую либу, в которой такой возврат не задокументирован.
У вас логика отклеилась. Фотоаппарат - инструмент и не фотографирует за вас, да и рисуете вы на компьютере сами, а не он за вас.
Любое дело, которое поможет убрать ТС с тротуаров на проезжую часть - богоугодно.
Как минимум перейти по ссылке на него и посмотреть что он из себя представляет.
Какая-то фантазия)
Пишу с SE 1го поколения, который 6s в корпусе 5s. Приложения работают нормально, Хабр вот читаю. Ничего не тупит. Обновления до сих пор еще бывают, в основном безопасности. Apple Music до сих пор слушаю с него.
Одно расстраивает - аккум стал совсем плох. Приходится таскать постоянно пауэр банк еще.
Не совсем верно выше выразился, лучше так
match key { case J: press Jcase K: press Kcase T: press Tcase D: press DПредположите, что есть некоторое дублирование намерений
case J -> press J, и поэтому эти вотcase Smthможно спрятать за некоторой абстракцией, и эти абстракции будут как некоторые контейнеры, в которые вы сложили вашу чистую логикуpress1...pressNПоэтому замените типовое выражение
match key { case Smth:на какой-либо спец символ, а все следующие за ним
case Smth:на другойПопробуйте взглянуть вот так
match key { case J:... case K:... case T:... case D:Предполагаю, что это по аналогии с хаскелем, в данном случае это "вход" в цепочку вычислений.
В хаскеле это будет что-то вроде
<$> параметр1 <*> параметр2 <*> параметр3 <*> параметр4
Когда уже есть некоторое понимание, то это кажется логичным и правильным и сами абстракции нет смысла держать в голове, остается только думать над смыслом, который хочешь выразить. Абстракции просто клей между частями головоломки
Поддержу автора, мне понравилось как надстройка над хаскелем, но еще выше уровнем.
не вижу проблем с чтением этого кода.
Обработка нажатий клавиатуры:
j - перемещение вниз
K - перемещение вниз
и т.д.
Возможно, есть шероховатости, но общая концепция понятна - отделить инструмент от бизнес-логики, что на самом деле, действительно, является проблемой разработки . Инструмент (ЯП) переплетен с предметной областью настолько, что разработчикам очень сложно выразить ясно свои намерения под тоннами абстракций, которые они пишут. Автор пытается эти абстракции как раз спрятать за спец символами, оставив чистую логику.
Не вижу проблем с изучением, как и любой язык. А абстракции на то и абстракции, чтобы один раз понять как они работают и потом не возвращаться к этому, оставив себе в качестве работы решение проблем бизнеса - конкретных задач, а не очередную борьбу выразить на очередном языке свои намерения.
С удовольствием прочитаю продолжение.
как в воду глядел
привет из 2025го от следующей версии - о1 (модель на основе рассуждений)
на самом деле это просто низкая инженерная культура. На java можно писать нормально, если не делать всё со всем связанным и всё подряд со скоупом public.
Все становится гораздо прозрачнее, если строить взаимодействие между пакетами только через интерфейсы и забыть про публичные классы
// создание DI контейнераfinal TinyDI notDI = new TinyDI();// инициализация - указываем все классы являющиеся зависимостямиnotDI.setup(List.of(Users.class,Sessions.class,LocaleStorage.class, BookRecordStorage.class,RestAPI.class,Expression.class, Json.class,PageHandler.class,ResourceHandler.class));По-моему вы просто реализовали свой контейнер IoC, а не DI. Не проще было использовать синглтоны с фабричными методами и не городить огород с контейнерами ?
Кмк идти по пути решения проблемы отладки, это как на паровоз прикручивать навороченные сенсоры отслеживания давления пара, чтобы понимать почему котлы взрываются. Вместо перехода на электродвигатели.
Как в свое время перешли с перфокарт, а затем с ассемблерного кода, так и сейчас пора перестать решать задачи компьютера человеком и перейти уже на языки еще более высокого уровня для решения прикладных задач, вместо решения проблем связки программист-машина.
А вот на мой взгляд, для разработчиков, умение лаконично и грамотно выразить свои мысли текстовым сообщением, гораздо важнее, чем трепаться по телефону. Это отнимает на порядок меньше времени, позволяет зафиксировать договоренности и имеет эффект отложенного анализа текста.
В конце концов, если вы текстом деньги зарабатываете, то нужно уметь его писать.
Кмк эта проблема слегка надумана и уйдет после того, как перестанут использоваться указатели напрямую и произойдет переход на функциональную парадигму (неизменяемые данные, объекты и т.п.)
List<?> twice = s.addAll(s); // просто сделает удвоение существующего списка при вызове метода.
О бессмертии мечтают миллионы людей – тех самых, которые мучительно думают, чем бы занять себя в дождливый воскресный вечер.