Нужен совет по изучению Java 21

а смысл учить язык 10-летней давности, в котором дофига всего изменилось, когда актуальные учебники есть.

Это не язык десятилетней давности, это подмножество современного языка. При чем, в реальных проектах это множество составляет 97%.

Там женериков нет. А так да, вполне пойдет.

Скучаная

А минусы будут?

Так это и есть минус для хобби-проекта. Скучного и на работе хватает.

Это ещё зачем? Кто тебя заставляет?

Предлагаешь мне на каждый чих самому с нуля их писать?

В дебиане видел пакет со SRFI для Chez Scheme. Можно на Chez Scheme писать на основе R7RS? И как с этим стандартом в самом Racket?

Отлично. Если надо переносимость, то на нём и писать. Примерно так: https://github.com/ecraven/r7rs-benchmarks

Chez это уже r7rs. Для Racket надо в начале написать #lang r7rs.

Спасибо! Скачал, потом посмотрю внимательнее. Пока не разобрал.

Да, и Chez Scheme приглянулся мне очень, как и Gambit, кстати, тоже. Например, понравилось, что Gambit легко создает JavaScript. И не такой большой получается выхлоп.

А еще такой вопрос, а что на счет ООП?

Ну, я понимаю, что ФП не одобряет (особенно clojure), но иногда хочется, особенно для библиотеки, которая заточена под GUI.

Что можно взять?

Смотрел TinyCLOS. Пока не решил. И еще не понял, как подключить, чтобы один исходный файл мог использоваться для разных реализаций. Может быть, твой пример выше подскажет.

Еще есть статьи по мотивам SICP, как имитировать классы с наследованием. Там выглядит почти все просто. Только я пока до конца не понял, как имитировать линеаризацию для множественного наследования в духе CLOS. Примерно представляю, но только примерно. Мне как раз пригодилась бы такая линеаризация. Может быть, что это даже лучший вариант для ООП.

Есть еще вариант - взять за основу записи из R7RS, но не уверен, что хороший вариант.

Ну, и совсем другой вариант - это просто положиться только на Racket c его ООП, но этого для хобби-проекта совсем не хотелось бы.

Что ты можешь сказать про ООП?

И я пока только присматриваюсь. Что мне нравится в Схеме - минимализм, изящность и функциональность, которых мне так не хватает в современном программировании! Для хобби-проекта

Смотрел TinyCLOS. Пока не решил. И еще не понял, как подключить, чтобы один исходный файл мог использоваться для разных реализаций. Может быть, твой пример выше подскажет.

Есть такое: https://github.com/ktakashi/r7rs-clos

А еще такой вопрос, а что на счет ООП?

А зачем? Мне в Racket ООП пригодился только при использовании графического интерфейса, да и то потому что интерфейс уже на ООП.

Я понимаю, зачем ООП в языках со статической типизацией: чтобы можно было сказать List<Element> и сложить в список любых наследников Element (который в идеале просто интерфейс). Но зачем он в динамическом языке? Практически всё, что можно сделать через ООП, можно сделать через структуры и замыкания. ((on-paint element) x y) работает ничуть не хуже, чем element.on_paint(x, y). Даже лучше, потому что у конкретного элемента можно поменять поле on-paint в любой момент.

Что мне нравится в Схеме - минимализм, изящность и функциональность, которых мне так не хватает в современном программировании! Для хобби-проекта

Я для своих проектов практически отказался от ООП и макросов именно из этих соображений. ООП необходимо только если есть сложная иерархия классов и заранее неизвестно какие классы будут добавлены в дальнейшем. Для хобби-проекта это очень вряд ли.

Так дженерики в джаве это тупо синтаксический сахар. Вот и полезно без них пописать, чтобы потом понимать, во что дженерики компилируются. А то бывают у людей недопонимания.

Так это и есть минус для хобби-проекта. Скучного и на работе хватает.

Ну смотря какая цель. Если что-то практическое сделать, то лучше скучный инструмент. Если с инструментом позабавиться - дело другое.

Предлагаешь мне на каждый чих самому с нуля их писать?

Их это кого? Чего тебе в Java не хватает? Что ты там собрался тянуть, да ещё и сотнями мегабайтов, как я понял? По-мне в Java из практического нужного только JSON не хватает. И это как раз то, что пишется в общем-то за несколько часов при большом желании. Всё остальное или есть, или есть хорошие библиотеки, которые совсем не занимают сотни мегабайтов.

Ну дженерики строго говоря не сахар. И да, гарантий во что они там компилируются и будут компилироваться через 10 лет у тебя нет никаких.

Не ну смотри, есть задачи где надо тянуть всякое жирное из предметной области (веб там, если фреймворками мазаться, а это всегда предпочтительно, т.к. какие-никакие гарантии стабильного и проверенного кода, значительно быстрее разработка, какие-то тонкие моменты прячет и делает за тебя, что может быть хорошо если ты не знаешь столько же сколько все разработчики фреймворка вместе взятые).

Всё остальное или есть, или есть хорошие библиотеки, которые совсем не занимают сотни мегабайтов.

А вот это утверждение - ложное. Смотри, я как-то растишку потыкал, мне понравилось очень как там clap сделан. У Java есть куча альтернатив, перечислять из которых имеет смысл только 3: The Apache Commons CLI (древний и куда менее удобный), JCommander - менее фичастый, picocli - очень фичастый, но очень неудобный, если надо изменить какое-то базовое поведение (например написать описание к enum параметрам или изменить выравнивание в description), да сделать всё это можно, но это уже далеко не тривиальная задача и надо влезать внутрь потрохов этой либы чтоб понять что и как там работает, т.к. документация с примерами только об очень базовых вещах и всё что есть это javadoc с грубым описанием тех или иных классов и методов половина из которых деприкейтед. А это как бы самая база для хеллоуворлдов, если даже в ней у Java сложности, значит всё не так уж и радостно.

По-моему при изучении джавы стоит делать упор на изучение jre вообще, а не на конкретную реализацию синтаксиса к нему.

Согласен, этот момент понимать нужно. Но, все же, я бы обучение без них не рекомендовал.

Их это кого?

Библиотеки.

Чего тебе в Java не хватает? Что ты там собрался тянуть, да ещё и сотнями мегабайтов, как я понял? По-мне в Java из практического нужного только JSON не хватает. И это как раз то, что пишется в общем-то за несколько часов при большом желании.

В каждом проекте это что-то свое. Где-то библиотека для работы со звуком, где-то с изображениями, где-то SQLite и т. д.
В том же Python или C/C++ это будет скорей всего «системная» библиотека установленная с помощью пакетного менеджера.

Я понять не могу, вы всем тредом учебников не читали никогда? Учебник - это комплекс из языка, апи, паттернов, библиотек и, прости Бжа, кодстайла. Это срез того, как язык использовался на момент написания учебника. Ради чего брать книгу 10-летней давности, материалу в которой лет ещё больше, и учиться по ней вместо актуальной? Читать срань про сервлеты и JAXB? Тяпать байты руками из InputStream’ов, и пучить глаза на web.xml? Чтобы доказать кому-то, что в отсталой джаве ничего не могло поменяться?

Учебников по джаве действительно никогда не читал. Изучал её больше с позиций байткода и реверса, возможность что-то на ней немного кодить побочно получилась.

Зачем тянуть SQLite в Java, когда у Java есть H2, который не привязывает тебя к нативным библиотекам?

Тяпать байты руками из InputStream’ов А как ты собрался с сокетами работать? Я понимаю что то что ты описал раньше было безальтернативно везде, даже там где это плохая идея, но представим, что ты хочешь решить сраную задачу, которую вот этот Синхронизация файлов чел не смог Чем синхронизировать файлы комп->телефон?

И сделать это на Java. Ваши действия (тебе на самом деле много не надо - файл вотчер и работа с сетью). Яндекс/гугл облака - хреновая идея.

Для линукса?

Ради чего брать книгу 10-летней давности

Погрузиться в историю. Нюхнуть пыли веков, так сказать %)

Почему многие верят, что где-то есть какая-то волшебная книжка, почитав которую сразу становишься синьором с зп $9000/наносек, и это только остальные погромисты про нее не рассказывают, дабы не палить контору.

Нет, книжками ты не отделаешься. Если уж выбрал этот путь, будь готов учиться всю жизнь (а в результате не осилить и половину)

Есть такое: https://github.com/ktakashi/r7rs-clos

Здорово! Тоже гляну вечерком

А зачем? Мне в Racket ООП пригодился только при использовании графического интерфейса, да и то потому что интерфейс уже на ООП.

Просто, чтобы перенести легаси моего собственного производства. А потом собрать wasm (через Chez Scheme) или JavaScript (через Gambit), навесить мосты с браузерным GUI

Не ну смотри, есть задачи где надо тянуть всякое жирное из предметной области (веб там, если фреймворками мазаться, а это всегда предпочтительно, т.к. какие-никакие гарантии стабильного и проверенного кода, значительно быстрее разработка, какие-то тонкие моменты прячет и делает за тебя, что может быть хорошо если ты не знаешь столько же сколько все разработчики фреймворка вместе взятые).

Это всё фигня. Просто бери com.sun.httpserver и фигачь свой веб. А если чувствуешь уверенность - бери TCPSocket и читай/пиши HTTP по строкам. Если совсем уж кажется странным - полно крохотных HTTP библиотечек, например nanohttpd.

А знания, не знания, это всё FUD чтобы запугивать неофитов. Нет там никаких сакральных моментов в Spring MVC, такая же шляпа, только жрёт много. Ещё порой и нифига не гибкая. Попробуй, например, через спринг вытащить ответ сервера, первую строчку, типа HTTP 200 SALAM вот тут SALAM попробуй вытащить. Насколько я помню, это вообще никак.

А вот это утверждение - ложное. Смотри, я как-то растишку потыкал, мне понравилось очень как там clap сделан. У Java есть куча альтернатив, перечислять из которых имеет смысл только 3: The Apache Commons CLI (древний и куда менее удобный), JCommander - менее фичастый, picocli - очень фичастый, но очень неудобный, если надо изменить какое-то базовое поведение (например написать описание к enum параметрам или изменить выравнивание в description), да сделать всё это можно, но это уже далеко не тривиальная задача и надо влезать внутрь потрохов этой либы чтоб понять что и как там работает, т.к. документация с примерами только об очень базовых вещах и всё что есть это javadoc с грубым описанием тех или иных классов и методов половина из которых деприкейтед. А это как бы самая база для хеллоуворлдов, если даже в ней у Java сложности, значит всё не так уж и радостно.

Если тебе нужны хелло ворлды, просто бери и парси аргументы вручную. Я на жаве 20 лет пишу, не один десяток CLI написал и ни разу мне даже в голову не пришло какими-то там библиотеками для парсинга аргументов пользоваться. Чего там парсить-то.

А по-мне жаву хорошо учить именно по версиям. Чтобы сократить объём когнитивной нагрузки. Ну и целом код без генериков никто из языка не убирал, хоть и встретить его нынче, наверное, редкость, но всё же это полноценная компилирующаяся жава и человек, который впадёт в ступор при виде такого кода, вероятно имеет пробелы в знаниях.

Я, конечно, не предлагаю остаться на 1.4. А начать с неё. Когда хорошо с ней разберётся человек, а отсутствие генериков ему в этом поможет, конечно нужно уже потом итеративно добавить генерики, потом уже и лямбды добавить, но всё это будет ложиться как синтаксический сахар на ментальную модель более простой явы. К примеру я хоть и понимаю, что лямбды это не совсем анонимные классы, но по факту для меня это до сих пор синтаксический сахар для анонимных классов. И когда я пишу код, очень часто я сначала пишу его через анонимный класс вместо лямбды, а потом уже через рефакторинг заменяю его лямбдой (есть в этом некоторые удобства).

Если надо взаимодействовать с сишными библиотеками, тут будет неудобно, да. Хотя вроде в последних версиях что-то улучшали, по foreign function api можно поискать, мне не приходилось этим пользоваться.

легаси моего собственного производства

Оно на CLOS? Если нет, то проще через структуры/записи работать.

Вручную лень, особенно когда аргументов много и они сложные, скажем 10+ аргументов из которых пара ещё в Enum должна быть, часть несовместимы между собой, уже не очень хочется ручками. А если вспомнить что хочется чтоб справка мультиязычная рендерилась и в ней всё правильно переносилось и отрисовывалось, то совсем уже руками не охота, да и проще по коду расставить аннотаций, чем ручками. Хеллоуворлд хеллоуворлду рознь. Я просто условные GNU утилиты все за уровень хеллоуворлдов считаю, ну кроме grep-а и sed-а пожалуй (там много нетривиальной логики и куча оптимизаций на скорость). А все эти ls/cat/less/man это всё хеллоуворлды, просто им лет много и они несут полезную нагрузку. Тем более picocli ещё и проблему автодополнения аргументов в линуксах из коробки решать умеет и всякие приятные штуки, вроде более безопасного ввода пароля, чтоб он не оставался в history. И вообще я сторонник того чтоб всё было однообразно, даже рендеринг справки. Вот только за основу надо брать как раз тот формат, который gnu утилиты приняли и используют (по крайней мере на Linux/BSD платформах, а на оффтопике и OSX там должно рендериться всё так как там у них принято). А не чтоб каждый лепил кто во что горазд. Потому какая-то прослойка, готовая этим всем заниматься идейно нужна.

Читать срань про сервлеты и JAXB?

В моих учебниках не было про JAXB.

Тяпать байты руками из InputStream’ов

А ты веселый. Вся жаба InputStream пропитана, не понятно, как ты без него собрался на ней писать.

и пучить глаза на web.xml?

В моих учебниках про это тоже не было.

Чтобы доказать кому-то, что в отсталой джаве ничего не могло поменяться?

Напоминаю. Новичку посоветовали брать книгу прям по свежайшей Жабе. В ответ ему посоветовали не париться о версиях, ибо ему придется искать новую книгу каждые полгода. Никто не говорил о старых книгах как цели.
Да и вообще, а книги хоть успевают за релизами?

1. Я это просто как пример привел.
2. SQLite стандарт. А вдруг моя поделка это читать SQLite-базы сгенерированные Firefox'ом?

К примеру я хоть и понимаю, что лямбды это не совсем анонимные классы, но по факту для меня это до сих пор синтаксический сахар для анонимных классов.

Не особо помогла твоя метода. лямбды это синтаксический сахар для методов а не классов. :)

И когда я пишу код, очень часто я сначала пишу его через анонимный класс вместо лямбды, а потом уже через рефакторинг заменяю его лямбдой (есть в этом некоторые удобства).

Я тоже так делаю, когда параметров много или типы сложные.

личная статистика по запросам на SO такова, что самые всратые запросы идут от котлинистов - народ совершенно не понимает ни как работает JVM, ни как работает платформа, точно также про протоколы совершенно не в теме и пр.

Котлин - это бейсик для мобилок.

Я понять не могу, вы всем тредом учебников не читали никогда? Учебник - это комплекс из языка, апи, паттернов, библиотек и, прости Бжа, кодстайла

у меня в 200x была книжка Java 2: The Complete Reference, в ней описывали какую-то дичь в духе как реализовать апплет игрушки в крестики-нолики, очень полезная книжка была, да.

Для того, чем сам пользуешься. Иначе затея из хобби превращается в работу, а работы и на работе хватает.

и ни разу мне даже в голову не пришло какими-то там библиотеками для парсинга аргументов пользоваться.

Значит они все нехороши. Потому как хорошая библиотека решает сразу же множество вопросов с длинными-короткими опциями, позиционными аргументами, проверками на допустимые значения, автоприведением типа и генерацией справки. Делать это же самое вручную можно, но зачем?

О раз уж тут жависты собрались (я наверное не про тебя, если ты автор бабашки или её пользователь), но всё же спрошу про такую библиотеку (это я с анона жаловался на picocli, потому как спать уже ушел, а в спальне у меня старый ноут с довольно древним оффтопиком и софтом весьма сомнительной безопасности, где я никуда не логинюсь по соображениям чтоб не увели аккаунт). Можно ли как-то переделать такое:

Usage: appname [-abcdehv] [-l=<level>] <some files and directories>
Description: some app for processing files
Arguments: 
      <some files and directories>
                      files and directories for processing
Options:
  -a, --archives      process archives
  -b, --basic         basic output
  -c, --creator       display creator
  -d, --description   display description
  -e, --editor        display editor
  -h, --help          display help and exit
  -l, --level         display very very long description which is too long for one
                        string. And it contains some Enum constants which need
                        descriptions too:
                        CONST1 - description 1
                        CONSTLONGER - description 2 which is too long too and
                        should be aligned too
                        CONST3 - description 3
                        CONST4 - description 4
  -v, --version       display version and exit

Usage: appname [-abcdehv] [-l=<level>] <some files and directories>
Description: some app for processing files
Arguments: 
      <some files and directories>
                      files and directories for processing
Options:
  -a, --archives      process archives
  -b, --basic         basic output
  -c, --creator       display creator
  -d, --description   display description
  -e, --editor        display editor
  -h, --help          display help and exit
  -l, --level         display very very long description which is too long for one
                      string. And it contains some Enum constants which need
                      descriptions too:
                        CONST1      - description 1
                        CONSTLONGER - description 2 which is too long too and
                        	      should be aligned too
                        CONST3      - description 3
                        CONST4      - description 4
  -v, --version       display version and exit

Да костылик который предлагает автор (скармливать куски строк - плохой вариант, т.к. размер терминала не всегда 80 символов и для разных языков будет разная длинна строк)

Оно на CLOS? Если нет, то проще через структуры/записи работать.

Да, на CLOS. В принципе, множественное наследование я заменить смогу, если что, на две независимые иерархии. В принципе, можно и в духе SICP сделать. Подход SICP очень легко расширяется под одиночное наследование. Подумаю

Записи рассматриваю. Вот, поэтому и заинтересовался R7RS, особенно для Chez Scheme (который умеет делать wasm). Оно же вроде как все же R6RS.

Но я пока только присматриваюсь.

Так-то на CLOS есть рабочее приложение (редактор простых диаграмм со стрелками, квадратиками, кружочками и текстом с экспортом в PDF / SVG / EMF). Может быть, когда-нибудь и выложу готовые сборки. Есть готовый под винду (через когда-то честно купленный LispWorks). Есть еще под GTK3 (через SBCL). Может быть, еще одумаюсь и вернусь к CL.

Чем больше знаю о других языках, о той же линеаризации в Scala, то тем больше начинаю уважать CLOS. Книга AMOP немного смутила касательно того, на какой кухне все же создается «эффективная функция» для обобщенной функции, но наверное, это не такой и плохой вариант при прочих равных и по сравнению с другими. И какой никакой стандарт в CL все же есть, и он более-менее соблюдается реализациями.

Только вот JavaScript сложно получить. Есть сообщения о том, что wasm хотят создавать через ECL, но еще вопрос, а каким по размеру будет код?

А сейчас в 2026 году десктопные приложения много-много сложнее распространять, чем вебовские. Пользователи уже так бездумно ставить десктопное приложение с непонятного сайта не будут, как легко делали раньше. А вот c джаваскриптом и wasm все многократно проще. Поэтому и задумался на счет Схемы.

Впрочем, это всего лишь хобби. Поэтому приоритет и темп соответствующие

Значит они все нехороши

Может быть и так, но я не смотрел ни одной, поэтому такой вывод я бы делать не стал.

Потому как хорошая библиотека решает сразу же множество вопросов с длинными-короткими опциями, позиционными аргументами, проверками на допустимые значения, автоприведением типа и генерацией справки.

Это, конечно, прекрасно, но мне никогда не было нужно. Например короткие опции я считаю чистым злом во плоти и реализовывать их никогда бы не стал. Автоприведение типа это вместо того, чтобы написать Integer.parseInt(arg)? Это я тоже никогда делать бы не стал, ненавижу декларативный код.

Делать это же самое вручную можно, но зачем?

Каждая зависимость это зло. Иногда неизбежное, но точно не в случае таких тривиальных задач.

Это, конечно, прекрасно, но мне никогда не было нужно.

Ну, всё правильно. Когда результат требует значительных усилий, при этом без него можно в принципе и обойтись, то и ну его нафиг. Чем больше ручной работы, тем легче согласиться, что это не нужно.

А вот когда результат достигается легко и без усилий, тогда можно сразу входить в тонкости и думать о пользе для пользователя (бадумс!), а не об экономии собственных усилий.

Каждая зависимость это зло

Ну, если с управлением зависимостями в языке беда, как в сишке, то ответ тот же. А если есть у языка нормальная инфраструктура, то зависимости это хорошо, а велосипеды — плохо.

Ну, если с управлением зависимостями в языке беда, как в сишке, то ответ тот же. А если есть у языка нормальная инфраструктура, то зависимости это хорошо, а велосипеды — плохо.

В корне не согласен. Инфраструктура тут не при чём. Каждая зависимость это технический долг. Следить за версиями. Обновлять код при обновлении зависимости. Быть готовым начать её поддерживать, если автор решит бросить проект. Причём практически всегда из кода библиотеки используется условных 10%, а 90% лежит мёртвым грузом, но проблемы приносит ровно те же.

Чем меньше зависимостей в проекте, тем лучше. Велосипеды это всегда лучше зависимости, просто иногда это слишком дорого и приходится мириться с ценой добавления зависимости. Но парсинг аргументов это точно не тот случай.

Каждая зависимость это технический долг. Следить за версиями.

Т.е. старый код в библиотеке это проблема, а в самописном велосипеде — нет? Ясно-понятно.

Быть готовым начать её поддерживать, если автор решит бросить проект.

Свой велосипед в поддержке не нуждается.

И т.д. и т.п. Единственное, в чём велосипеды выигрывают это в возможности почесать NIH синдром за счёт работодателя.