Сообщение Re[3]: Отказаться от кул-фреймворков и вернуться к истокам - от 02.06.2022 20:16
Изменено 02.06.2022 20:18 vsb
Re[3]: Отказаться от кул-фреймворков и вернуться к истокам - пл
Здравствуйте, scf, Вы писали:
vsb>>Я давно мечтаю написать для жавы эдакое переосмысление всей экосистемы. Начиная от инструмента сборки и заканчивая переписыванием всей стандартной мишуры — http, json и тд. Но вряд ли возьмусь, слишком много времени и практически гарантированно в ящик. Но думал много над этим.
scf>А надо? jdk-http — это отличный http клиент
Против jdk ничего против не имею (ну если не считать старых классов из 90-х, но почти всему уже есть современная замена).
> jackson тоже близок к идеалу
Он неимоверно далёк от моего идеала. Парсинг json делается в несколько сотен строк. Форматирование жсон делается ещё короче. Это несколько килобайтов байткода. Сколько мегабайтов и десятков тысяч строк написано в жаксоне я не знаю, и знать не хочу.
> mvn при всех своих недостатках отлично выполняет свою задачу
А мне не нравятся недостатки.
> Можешь вкратце описать, как ты видишь дивный новый мир
1. Общее видение: максимальная простота. В том числе простота реализации Скорость там, где это не мешает простоте. Всё максимально же модуляризировано. Многие концепции вроде маппингов не нужны. Если ради простоты надо написать немного скучного кода, это нормально. Если ради удобного маппинга объектов на БД нужна библиотека на сто тысяч строк кода, значит разработчик будет сам писать маппинги, руками. А библиотека на несколько сотен строк даст ему удобный апи для этого, не более. В целом мне импонирует подход го. Можно это моё видение считать натягиванием мира го на жаву.
2. Использование native (graal). Всё должно быть оптимизировано под эту технологию. Рефлекшна не должно быть (ну по крайней мере там, где без него можно, а можно практически везде).
3. Сборка. Для сборки проекта пишется отдельная программа-сборщик. С нуля её писать долго, поэтому предоставляется библиотека, которая делает удобным написание этой программы-сборщика. Что-то вроде build.gradle, только на жаве и попроще. Ну и какой-то cli, который автоматически компилирует этот скрипт, опционально делает его native (когда мы уже закончили писать скрипт и хотим просто его запускать). Конечная цель — чтобы с одной стороны написание скрипта не требовало изучение чего-либо кроме Java (ну и этой библиотеки, но опять же библиотека должна быть максимально неинтрузивной), с другой стороны чтобы сборка работала миллисекунды, а не десятки секунд.
4. Для отладки инструментарий для автоматической перекомпиляции изменённых файлов, перезагрузки классов и тд. В целом это есть для других фреймворков, тут ничего нового.
5. Для типовых веб-сервисов набор минималистичных библиотек, реализующих ровно то, что реализовывать самому скучно. HTTP, JSON тот же. Также обёртка вокруг JDBC, текущий API не очень хорош. Причём очень важно, чтобы реализация этих библиотек была простая, чтобы всегда можно было провалиться в реализацию и легко прочитать её. К примеру асинхронность не нужна, что убирает уйму сложности. В целом каждая отдельная библиотека должна занимать несколько тысяч строк от силы.
6. Ненужное — не нужно. HTTPS не нужен, все ставят реверс-прокси. Какие-то мегасуперпупер оптимизации не нужны, быстрей netty всё равно не сделаешь.
7. Использование последних стандартов, к примеру records и тд. В этом плане я жду некоторые фичи вроде string interpolation, которые могут очень круто сочетаться с тем же SQL.
Попробую свою идею выразить по-другому. Представь, что у тебя есть компилятор жавы и всё. Мавена нет. Спринга нет. Тебя заперли на год и тебе надо написать веб-сервис. Ты сначала пишешь тулзу для сборки на коленке, потом пишешь реализацию HTTP на коленке, потом неминуемо напишешь обёртку вокруг JDBC, вручную сериализацию и парсинг JSON. Потом ты напишешь второй проект, третий. Потом из этих трёх проектов попробуешь вытащить какие-то общие куски кода. Вот эти общие куски кода это и есть моё видение. Для типовых проектов, которые обрабатывают HTTP запросы и лезут в реляционную СУБД. По крайней мере для таких, с которыми я сталкиваюсь.
> Возможно, это уже запилено для более "продвинутых" языков.
Как я уже написал, в Го в целом это запилено. К сборке там другой подход, но мне любопытен именно мой вариант, мне он кажется интересным для исследования.
В целом моя проблема с популярными подходами в том, что 20% их кода решает 80% проблем, но они не останавливаются, а пишут ещё 80% кода, чтобы решить оставшиеся 20% проблем. Вот мне хотелось бы остановиться на первых 20%. Мне кажется, что это было бы в итоге лучше.
vsb>>Я давно мечтаю написать для жавы эдакое переосмысление всей экосистемы. Начиная от инструмента сборки и заканчивая переписыванием всей стандартной мишуры — http, json и тд. Но вряд ли возьмусь, слишком много времени и практически гарантированно в ящик. Но думал много над этим.
scf>А надо? jdk-http — это отличный http клиент
Против jdk ничего против не имею (ну если не считать старых классов из 90-х, но почти всему уже есть современная замена).
> jackson тоже близок к идеалу
Он неимоверно далёк от моего идеала. Парсинг json делается в несколько сотен строк. Форматирование жсон делается ещё короче. Это несколько килобайтов байткода. Сколько мегабайтов и десятков тысяч строк написано в жаксоне я не знаю, и знать не хочу.
> mvn при всех своих недостатках отлично выполняет свою задачу
А мне не нравятся недостатки.
> Можешь вкратце описать, как ты видишь дивный новый мир
1. Общее видение: максимальная простота. В том числе простота реализации Скорость там, где это не мешает простоте. Всё максимально же модуляризировано. Многие концепции вроде маппингов не нужны. Если ради простоты надо написать немного скучного кода, это нормально. Если ради удобного маппинга объектов на БД нужна библиотека на сто тысяч строк кода, значит разработчик будет сам писать маппинги, руками. А библиотека на несколько сотен строк даст ему удобный апи для этого, не более. В целом мне импонирует подход го. Можно это моё видение считать натягиванием мира го на жаву.
2. Использование native (graal). Всё должно быть оптимизировано под эту технологию. Рефлекшна не должно быть (ну по крайней мере там, где без него можно, а можно практически везде).
3. Сборка. Для сборки проекта пишется отдельная программа-сборщик. С нуля её писать долго, поэтому предоставляется библиотека, которая делает удобным написание этой программы-сборщика. Что-то вроде build.gradle, только на жаве и попроще. Ну и какой-то cli, который автоматически компилирует этот скрипт, опционально делает его native (когда мы уже закончили писать скрипт и хотим просто его запускать). Конечная цель — чтобы с одной стороны написание скрипта не требовало изучение чего-либо кроме Java (ну и этой библиотеки, но опять же библиотека должна быть максимально неинтрузивной), с другой стороны чтобы сборка работала миллисекунды, а не десятки секунд.
4. Для отладки инструментарий для автоматической перекомпиляции изменённых файлов, перезагрузки классов и тд. В целом это есть для других фреймворков, тут ничего нового.
5. Для типовых веб-сервисов набор минималистичных библиотек, реализующих ровно то, что реализовывать самому скучно. HTTP, JSON тот же. Также обёртка вокруг JDBC, текущий API не очень хорош. Причём очень важно, чтобы реализация этих библиотек была простая, чтобы всегда можно было провалиться в реализацию и легко прочитать её. К примеру асинхронность не нужна, что убирает уйму сложности. В целом каждая отдельная библиотека должна занимать несколько тысяч строк от силы.
6. Ненужное — не нужно. HTTPS не нужен, все ставят реверс-прокси. Какие-то мегасуперпупер оптимизации не нужны, быстрей netty всё равно не сделаешь.
7. Использование последних стандартов, к примеру records и тд. В этом плане я жду некоторые фичи вроде string interpolation, которые могут очень круто сочетаться с тем же SQL.
Попробую свою идею выразить по-другому. Представь, что у тебя есть компилятор жавы и всё. Мавена нет. Спринга нет. Тебя заперли на год и тебе надо написать веб-сервис. Ты сначала пишешь тулзу для сборки на коленке, потом пишешь реализацию HTTP на коленке, потом неминуемо напишешь обёртку вокруг JDBC, вручную сериализацию и парсинг JSON. Потом ты напишешь второй проект, третий. Потом из этих трёх проектов попробуешь вытащить какие-то общие куски кода. Вот эти общие куски кода это и есть моё видение. Для типовых проектов, которые обрабатывают HTTP запросы и лезут в реляционную СУБД. По крайней мере для таких, с которыми я сталкиваюсь.
> Возможно, это уже запилено для более "продвинутых" языков.
Как я уже написал, в Го в целом это запилено. К сборке там другой подход, но мне любопытен именно мой вариант, мне он кажется интересным для исследования.
В целом моя проблема с популярными подходами в том, что 20% их кода решает 80% проблем, но они не останавливаются, а пишут ещё 80% кода, чтобы решить оставшиеся 20% проблем. Вот мне хотелось бы остановиться на первых 20%. Мне кажется, что это было бы в итоге лучше.
Re[3]: Отказаться от кул-фреймворков и вернуться к истокам -
Здравствуйте, scf, Вы писали:
vsb>>Я давно мечтаю написать для жавы эдакое переосмысление всей экосистемы. Начиная от инструмента сборки и заканчивая переписыванием всей стандартной мишуры — http, json и тд. Но вряд ли возьмусь, слишком много времени и практически гарантированно в ящик. Но думал много над этим.
scf>А надо? jdk-http — это отличный http клиент
Против jdk ничего против не имею (ну если не считать старых классов из 90-х, но почти всему уже есть современная замена).
> jackson тоже близок к идеалу
Он неимоверно далёк от моего идеала. Парсинг json делается в несколько сотен строк. Форматирование жсон делается ещё короче. Это несколько килобайтов байткода. Сколько мегабайтов и десятков тысяч строк написано в жаксоне я не знаю, и знать не хочу.
> mvn при всех своих недостатках отлично выполняет свою задачу
А мне не нравятся недостатки.
> Можешь вкратце описать, как ты видишь дивный новый мир
1. Общее видение: максимальная простота. В том числе простота реализации Скорость там, где это не мешает простоте. Всё максимально же модуляризировано. Многие концепции вроде маппингов не нужны. Если ради простоты надо написать немного скучного кода, это нормально. Если ради удобного маппинга объектов на БД нужна библиотека на сто тысяч строк кода, значит разработчик будет сам писать маппинги, руками. А библиотека на несколько сотен строк даст ему удобный апи для этого, не более. В целом мне импонирует подход го. Можно это моё видение считать натягиванием мира го на жаву.
2. Использование native (graal). Всё должно быть оптимизировано под эту технологию. Рефлекшна не должно быть (ну по крайней мере там, где без него можно, а можно практически везде). JVM используется только во время разработки, чтобы не ждать компиляции.
3. Сборка. Для сборки проекта пишется отдельная программа-сборщик. С нуля её писать долго, поэтому предоставляется библиотека, которая делает удобным написание этой программы-сборщика. Что-то вроде build.gradle, только на жаве и попроще. Ну и какой-то cli, который автоматически компилирует этот скрипт, опционально делает его native (когда мы уже закончили писать скрипт и хотим просто его запускать). Конечная цель — чтобы с одной стороны написание скрипта не требовало изучение чего-либо кроме Java (ну и этой библиотеки, но опять же библиотека должна быть максимально неинтрузивной), с другой стороны чтобы сборка работала миллисекунды, а не десятки секунд.
4. Для отладки инструментарий для автоматической перекомпиляции изменённых файлов, перезагрузки классов и тд. В целом это есть для других фреймворков, тут ничего нового.
5. Для типовых веб-сервисов набор минималистичных библиотек, реализующих ровно то, что реализовывать самому скучно. HTTP, JSON тот же. Также обёртка вокруг JDBC, текущий API не очень хорош. Причём очень важно, чтобы реализация этих библиотек была простая, чтобы всегда можно было провалиться в реализацию и легко прочитать её. К примеру асинхронность не нужна, что убирает уйму сложности. В целом каждая отдельная библиотека должна занимать несколько тысяч строк от силы.
6. Ненужное — не нужно. HTTPS не нужен, все ставят реверс-прокси. Какие-то мегасуперпупер оптимизации не нужны, быстрей netty всё равно не сделаешь.
7. Использование последних стандартов, к примеру records и тд. В этом плане я жду некоторые фичи вроде string interpolation, которые могут очень круто сочетаться с тем же SQL.
Попробую свою идею выразить по-другому. Представь, что у тебя есть компилятор жавы и всё. Мавена нет. Спринга нет. Тебя заперли на год и тебе надо написать веб-сервис. Ты сначала пишешь тулзу для сборки на коленке, потом пишешь реализацию HTTP на коленке, потом неминуемо напишешь обёртку вокруг JDBC, вручную сериализацию и парсинг JSON. Потом ты напишешь второй проект, третий. Потом из этих трёх проектов попробуешь вытащить какие-то общие куски кода. Вот эти общие куски кода это и есть моё видение. Для типовых проектов, которые обрабатывают HTTP запросы и лезут в реляционную СУБД. По крайней мере для таких, с которыми я сталкиваюсь.
> Возможно, это уже запилено для более "продвинутых" языков.
Как я уже написал, в Го в целом это запилено. К сборке там другой подход, но мне любопытен именно мой вариант, мне он кажется интересным для исследования.
В целом моя проблема с популярными подходами в том, что 20% их кода решает 80% проблем, но они не останавливаются, а пишут ещё 80% кода, чтобы решить оставшиеся 20% проблем. Вот мне хотелось бы остановиться на первых 20%. Мне кажется, что это было бы в итоге лучше.
vsb>>Я давно мечтаю написать для жавы эдакое переосмысление всей экосистемы. Начиная от инструмента сборки и заканчивая переписыванием всей стандартной мишуры — http, json и тд. Но вряд ли возьмусь, слишком много времени и практически гарантированно в ящик. Но думал много над этим.
scf>А надо? jdk-http — это отличный http клиент
Против jdk ничего против не имею (ну если не считать старых классов из 90-х, но почти всему уже есть современная замена).
> jackson тоже близок к идеалу
Он неимоверно далёк от моего идеала. Парсинг json делается в несколько сотен строк. Форматирование жсон делается ещё короче. Это несколько килобайтов байткода. Сколько мегабайтов и десятков тысяч строк написано в жаксоне я не знаю, и знать не хочу.
> mvn при всех своих недостатках отлично выполняет свою задачу
А мне не нравятся недостатки.
> Можешь вкратце описать, как ты видишь дивный новый мир
1. Общее видение: максимальная простота. В том числе простота реализации Скорость там, где это не мешает простоте. Всё максимально же модуляризировано. Многие концепции вроде маппингов не нужны. Если ради простоты надо написать немного скучного кода, это нормально. Если ради удобного маппинга объектов на БД нужна библиотека на сто тысяч строк кода, значит разработчик будет сам писать маппинги, руками. А библиотека на несколько сотен строк даст ему удобный апи для этого, не более. В целом мне импонирует подход го. Можно это моё видение считать натягиванием мира го на жаву.
2. Использование native (graal). Всё должно быть оптимизировано под эту технологию. Рефлекшна не должно быть (ну по крайней мере там, где без него можно, а можно практически везде). JVM используется только во время разработки, чтобы не ждать компиляции.
3. Сборка. Для сборки проекта пишется отдельная программа-сборщик. С нуля её писать долго, поэтому предоставляется библиотека, которая делает удобным написание этой программы-сборщика. Что-то вроде build.gradle, только на жаве и попроще. Ну и какой-то cli, который автоматически компилирует этот скрипт, опционально делает его native (когда мы уже закончили писать скрипт и хотим просто его запускать). Конечная цель — чтобы с одной стороны написание скрипта не требовало изучение чего-либо кроме Java (ну и этой библиотеки, но опять же библиотека должна быть максимально неинтрузивной), с другой стороны чтобы сборка работала миллисекунды, а не десятки секунд.
4. Для отладки инструментарий для автоматической перекомпиляции изменённых файлов, перезагрузки классов и тд. В целом это есть для других фреймворков, тут ничего нового.
5. Для типовых веб-сервисов набор минималистичных библиотек, реализующих ровно то, что реализовывать самому скучно. HTTP, JSON тот же. Также обёртка вокруг JDBC, текущий API не очень хорош. Причём очень важно, чтобы реализация этих библиотек была простая, чтобы всегда можно было провалиться в реализацию и легко прочитать её. К примеру асинхронность не нужна, что убирает уйму сложности. В целом каждая отдельная библиотека должна занимать несколько тысяч строк от силы.
6. Ненужное — не нужно. HTTPS не нужен, все ставят реверс-прокси. Какие-то мегасуперпупер оптимизации не нужны, быстрей netty всё равно не сделаешь.
7. Использование последних стандартов, к примеру records и тд. В этом плане я жду некоторые фичи вроде string interpolation, которые могут очень круто сочетаться с тем же SQL.
Попробую свою идею выразить по-другому. Представь, что у тебя есть компилятор жавы и всё. Мавена нет. Спринга нет. Тебя заперли на год и тебе надо написать веб-сервис. Ты сначала пишешь тулзу для сборки на коленке, потом пишешь реализацию HTTP на коленке, потом неминуемо напишешь обёртку вокруг JDBC, вручную сериализацию и парсинг JSON. Потом ты напишешь второй проект, третий. Потом из этих трёх проектов попробуешь вытащить какие-то общие куски кода. Вот эти общие куски кода это и есть моё видение. Для типовых проектов, которые обрабатывают HTTP запросы и лезут в реляционную СУБД. По крайней мере для таких, с которыми я сталкиваюсь.
> Возможно, это уже запилено для более "продвинутых" языков.
Как я уже написал, в Го в целом это запилено. К сборке там другой подход, но мне любопытен именно мой вариант, мне он кажется интересным для исследования.
В целом моя проблема с популярными подходами в том, что 20% их кода решает 80% проблем, но они не останавливаются, а пишут ещё 80% кода, чтобы решить оставшиеся 20% проблем. Вот мне хотелось бы остановиться на первых 20%. Мне кажется, что это было бы в итоге лучше.