Нужен совет по изучению 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 там должно рендериться всё так как там у них принято). А не чтоб каждый лепил кто во что горазд. Потому какая-то прослойка, готовая этим всем заниматься идейно нужна.