Знаю что для android разработки часто используют обфускацию, вы используете это и для enterprise web?
obj1 & obj2. obj3. someField .~ «someValue»
Выглядит как черная магия и призыв драконов. Понятно, что все дело в практике, но мне кажется синтаксис не должен быть слишком пугающим и магическим. Лучше сделать что-то явно, чем неявно.
ФП только изучаю, но в целом уже сейчас понятны преимущества подхода ФП
Увы я в ФП новичок, но поверхностного знакомства хватило понять, что система типов строится куда логичней и проще.
Но за кадром остается много других вещей. Насколько гибче получится сделать микросервис принимающий данные с клиента, обрабатывающий эти данные и сохраняющий их в БД?
Ну т.е. реализация на java: spring boot + data, описали модели, DTO, наставили аннотаций, описали репозитории, сервисы, контроллеры. Нужны новые трансформации данных — поправили сервисы, добавили контроллеры, все работает. Нужны изменения в структуре данных — добавили поле в модель, dto, добавили колонку в бд, все работает.
Насколько в haskel / erlang / lisp это сделать проще, гибче?
Анемичные модели, dto vs entity это проблемы не java, а в целом ООП подхода. Логика в моделях в первую очередь должна быть связана непосредственно с данными модели, как-то – валидация данных, констрейнты. Там где логика завязана на несколько моделей, в дело вступают сервисы.
Возможно, как вы говорите ООП мешает, но какие у нас альтернативы?
Отличная вещь, но не везде он применим. В частности бывают проблемы с hibernat
А конкретнее в чем проблемы?
В legacy проектах его не встретишь.
Вся прелесть lombok, что его можно просто подключить и использовать. Свежий код пишем с его использованием, старый код постепенно рефакторим.
только в Java использовать иммутабельные структуры попросту неудобно. Например, как мне без мутаций поменять поле в цепочке объектов obj1.obj2.obj3.someField?
Соглашусь, неудобно. Можете показать пример технологии, где это сделать удобней?
Мы могли бы сделать тип Email, а не использовать String с аннотацией.
Так ведь никто не запрещает.
Или проверить статически что в массиве не меньше N элементов.
Вот только большая часть данных существует только в рантайме, потому статические проверки не будут иметь смысл.
Инъекция зависимостей, репозитарии Spring Data, маппинг Hibernate — все эти вещи можно было бы описать статически.
Так люди же намеренно пришли от статического к динамическому связыванию. Все реализации фабрик, сервисов, репозиториев можно и сейчас закостылить в лоб, вот только такой код не будет гибким для изменений.
Судя по критике — мутабельность, система типов, IoC — мне показалось, что вы больше приверженец ФП, я прав?
Синтаксис даже слишком простой, что выливается в огромное количество бойлерплейта.
Если вы про getter / setter, то Lombok решает эту проблему в 2 аннотации на классе (Getter / Setter). Нужен equals / hashCode – @EqualsAndHashCode. Нужен конструктор — @AllArgsConstructor. Нужен билдер — Builder, ну и т.д.
ООП в java это по большей части overengineering, который не решает реальных проблем
А подробнее можно о чем речь?
мутабильность спокойно ломает инкапсуляцию
Никто вам не запрещает писать безопасный код. Любой язык позволяет писать хорошо или плохо. Не хотите мутабельность — используйте immutable типы и final переменные.
нездоровая любовь к рефлексии, которые мешают писать надёжный код
Опять же, можно подробнее о чем речь?
Ну и NPE, да.
Для полей классов или аргументов методов можно поставить аннотацию @NonNull и все проверки будут сделаны за нас. Что касается цепочки вызовов, тут да, соглашусь, не хватает ?.
С одной стороны вы правы, что метасимволы дают представление о том, что перед нами. Это удобно, когда ты открыл файл скрипта текстовым редактором и читаешь его.
С другой стороны, это пережиток прошлого, поскольку разработка ведется в средах разработки, которые дают вам всю эту информацию, используя подсветку синтаксиса и другие подсказки.
В свое время была популярна венгерская нотация именования переменных, когда перед именем указывали тип переменной. Тогда это давало понять тип переменной без необходимости искать ее объявление в коде, но сейчас эту задачу решают среды разработки, не захламляя код.
Подобные заявления походят на бородатый анекдот: «Пастернака не читал, но осуждаю.»
У java довольно простой, лаконичный синтаксис и хорошо проработанный ООП, которым не каждый ЯП похвастается.
У java хорошая обратная совместимость версий (местами это даже смущает).
У java огромное сообщество, огромное кол-во библиотек и фреймворков.
У java самодокументируемый код, всегда есть возможность посмотреть не только документацию по методу, но и саму его реализацию с комментариями авторов.
За счет jit компиляции производительность «горячих» методов не сильно уступает нативному коду.
Безусловно у любого ЯП есть огрехи, но хотелось бы услышать конкретные аргументы нежели эмоциональные выпады.
C# в плане концепции языка — это калька с java. Но надо отдать должное MS, они добавили свои дополнительные плюшки и хорошо поработали над совместимостью со старым C кодом. Для desktop приложений под windows C#/.Net это достойная альтернатива.
Не совсем так. 15 лет назад у каждого браузера реализация DOM и прочих Web Api сильно отличалась от других. И JQ появился, чтобы исключить зависимость от каждого конкретного браузера, чтобы дать возможность разработчикам писать кроссбраузерный код.
В современном же вебе JQ потерял свою актуальность в связи с серьезной работой комитетов w3c по продвижению и утверждению web стандартов, и самое главное, в связи с переходом разработчиков на прогрессивные веб-фреймворки (React, Vue, Angular).
Не совсем понимаю от чего у вас так «пригорело». Во всех указанных вами постах авторы делятся личным опытом, полезность которого сообщество вольно оценивать. Бывает, листаешь хабр без какой-либо цели, но натолкнувшись на интересный заголовок из твоей или смежной области увлекаешься, решаешься опробовать что-то новое.
то есть ещё разок — статью с плюсовым рейтингом о чем-то там на С писал человек, который не в курсе о том, как работает strcat
Если вы внимательно читали, то вторая статья о том, как под python собрать dll и делать вызов функций, а не о качественной разработке программ на С…
Не примите за осуждение, просто небольшие замечания по вашему репо:
1. Не хватает Readme с описанием проекта. Иначе, только провалившись в исходники, можно понять, что это свой игровой движок для шашек, домино и т.п.
2. Проект видимо живет очень очень давно, поскольку нет системы сборки, это же чудовищно неудобно оперировать десятками файлов. Также нет и намека на es6 и выше, а в вашем движке, думаю, это сильно бы упростило жизнь.
3. В html не хватает doctype (без него браузеры работают в quirk mode). Inline стилей в html лучше избегать, также как избегать абсолютных размеров вида 411px.
Думаю, если порефакторить код, сделать его читаемым, расширяемым, прикрутить webpack, дополнить документацией, то у вас выйдет очень популярный проект.
Соглашусь с частью ваших замечаний, но с некоторыми не соглашусь.
код на нём низкоинформативен
Зависит от компетентности разработчика. Хороший разработчик способен писать читаемый, понятный, «чистый» код.
о типах переменных остаётся только догадываться
Порой сама среда разработки способна подсказать тип на основе синтаксического анализа. Также помогает jsdoc и принципы контрактного программирования. Если уж совсем хочется typesafety, то TypeScript ваш вариант.
Асинхронщина — отдельная пакость
В мире js используется кооперативная многозадачность. И по опыту скажу, что для простых задач это лучше вытесняющей многозадачности (aka многопоточность), где с синхронизацией (мьютексы, атомики, happens before, видимость памяти) можно голову сломать.
мозг намного лучше воспринимает алгоритм, действия которого выполняются последовательно
Все верно, для этого в спеку ввели синтаксис async / await, который позволяет писать код последовательно:
class RestApi {
async doSome() {
...
}
}
async function main() {
const rest = new RestApi();
const { result } = await rest.doSome();
...
}
В заключении скажу, js не идеален, никто с этим не спорит. Но язык развивается, совершенствуется, и думаю, он еще нас приятно удивит.
Я прекрасно понимаю вашу позицию. Я был столь же категоричен раньше. Сейчас же я более сдержан в своих требованиях и ожиданиях.
Количество функций в ЯП не бесконечное.
Оно конечно, как и все в реальном мире. Но оно (количество) изменчиво.
Я привел вам простой пример о функциях массивов и строк в php. Их более двух сотен. Нужно ли помнить их все? Используются ли они все в реальной жизни? Помните ли и используете ли вы их сами?
Принцип Парето никто не отменял: в разработке в 80% случаев используется 20% функционала ЯП / фреймворка.
Это не значит что надо брать д-еба который не знает программирования.
Не надо в крайности бросаться. Я лишь акцентирую внимание на необходимой достаточности знаний.
Внутренние исключения нужно или обработать или преобразовать в доменное исключение.
Все верно, нужны исключения уровня приложения, и мои тезисы не противоречат этому. Разница лишь в том, делать ли ваш AppException checked или unchecked?
Сделав его checked, вы обязаны обрабатывать свои исключения или прокидывать выше. Это хорошо работает на небольшой кодовой базе. Но когда у вас тысячи классов с сотней методов, то выясняется, что ВСЕ они throws AppException. А потом еще выясняется, что в подавляющем большинстве методов идет простая обертка исключений вида:
Удобно ли это при разработке? Стоит ли надуманное разделение checked / unchecked такого шаблонного кода? Кроме того, checked исключения вы не сможете использовать внутри стримов (stream api), а это явное упущение.
Как я и упомянул, многие фреймворки (тот же spring) перешли на unchecked исключения уровня приложения, и в этом я с ними солидарен.
А вот знать какие функции есть в языке и какое их назначение — особой проблемы нет
Что тогда вы подразумеваете под словами знать функции?
В том же php банально для массивов и строк порядка сотен функций. Помнить их все поименно не имеет практического смысла. Больший смысл имеет знать, что есть те или иные группы функций для определенного случая.
Заказчик бывает доволен сайтом который грузится 10 секунд и имеет целый набор уязвимостей.
Все должно быть регламентировано, иначе можно бесконечно долго доводить до «идеала».
Допустим, время отклика приложения было 10сек, вас это не устроило, вы оптимизировали работу и добились отклика в 1сек… а почему не 0,1сек… почему не 0,01сек? Где грань?
Не стоит судить так категорично. Невозможно знать всю стандартную библиотеку языка, т.к. языки развиваются, если только они не мертвые. Также невозможно знать все особенности всех библиотек и фреймворков для этого языка. Везде нужна своя мера, в этом суть.
В конечном счете значение имеет то, как, имея какое-то знание средств языка, ты сможешь решить ту или иную задачу и как сделаешь это эффективно… или условно эффективно, лишь бы заказчик был доволен.
Выносить общие поля сущностей в базовый класс - это плохой подход. Тем более, если эти поля используются в качестве первичного ключа.
В целом наследование в ООП нужно применять с предельной осторожностью, т.к. несет проблемы, и в 99.99% случаев оно вам не нужно.
ну право же, не надо голословных заявлений…
Знаю что для android разработки часто используют обфускацию, вы используете это и для enterprise web?
Выглядит как черная магия и призыв драконов. Понятно, что все дело в практике, но мне кажется синтаксис не должен быть слишком пугающим и магическим. Лучше сделать что-то явно, чем неявно.
Увы я в ФП новичок, но поверхностного знакомства хватило понять, что система типов строится куда логичней и проще.
Но за кадром остается много других вещей. Насколько гибче получится сделать микросервис принимающий данные с клиента, обрабатывающий эти данные и сохраняющий их в БД?
Ну т.е. реализация на java: spring boot + data, описали модели, DTO, наставили аннотаций, описали репозитории, сервисы, контроллеры. Нужны новые трансформации данных — поправили сервисы, добавили контроллеры, все работает. Нужны изменения в структуре данных — добавили поле в модель, dto, добавили колонку в бд, все работает.
Насколько в haskel / erlang / lisp это сделать проще, гибче?
Возможно, как вы говорите ООП мешает, но какие у нас альтернативы?
А конкретнее в чем проблемы?
Вся прелесть lombok, что его можно просто подключить и использовать. Свежий код пишем с его использованием, старый код постепенно рефакторим.
Соглашусь, неудобно. Можете показать пример технологии, где это сделать удобней?
Так ведь никто не запрещает.
Вот только большая часть данных существует только в рантайме, потому статические проверки не будут иметь смысл.
Так люди же намеренно пришли от статического к динамическому связыванию. Все реализации фабрик, сервисов, репозиториев можно и сейчас закостылить в лоб, вот только такой код не будет гибким для изменений.
Судя по критике — мутабельность, система типов, IoC — мне показалось, что вы больше приверженец ФП, я прав?
Если вы про getter / setter, то Lombok решает эту проблему в 2 аннотации на классе (Getter / Setter). Нужен equals / hashCode – @EqualsAndHashCode. Нужен конструктор — @AllArgsConstructor. Нужен билдер — Builder, ну и т.д.
А подробнее можно о чем речь?
Никто вам не запрещает писать безопасный код. Любой язык позволяет писать хорошо или плохо. Не хотите мутабельность — используйте immutable типы и final переменные.
Опять же, можно подробнее о чем речь?
Для полей классов или аргументов методов можно поставить аннотацию @NonNull и все проверки будут сделаны за нас. Что касается цепочки вызовов, тут да, соглашусь, не хватает ?.
А чем именно многословна и прожорлива?
А чем именно по вашему плоха объектная модель java? и почему java не для энтерпрайз?
С другой стороны, это пережиток прошлого, поскольку разработка ведется в средах разработки, которые дают вам всю эту информацию, используя подсветку синтаксиса и другие подсказки.
В свое время была популярна венгерская нотация именования переменных, когда перед именем указывали тип переменной. Тогда это давало понять тип переменной без необходимости искать ее объявление в коде, но сейчас эту задачу решают среды разработки, не захламляя код.
Подобные заявления походят на бородатый анекдот: «Пастернака не читал, но осуждаю.»
У java довольно простой, лаконичный синтаксис и хорошо проработанный ООП, которым не каждый ЯП похвастается.
У java хорошая обратная совместимость версий (местами это даже смущает).
У java огромное сообщество, огромное кол-во библиотек и фреймворков.
У java самодокументируемый код, всегда есть возможность посмотреть не только документацию по методу, но и саму его реализацию с комментариями авторов.
За счет jit компиляции производительность «горячих» методов не сильно уступает нативному коду.
Безусловно у любого ЯП есть огрехи, но хотелось бы услышать конкретные аргументы нежели эмоциональные выпады.
В современном же вебе JQ потерял свою актуальность в связи с серьезной работой комитетов w3c по продвижению и утверждению web стандартов, и самое главное, в связи с переходом разработчиков на прогрессивные веб-фреймворки (React, Vue, Angular).
Если вы внимательно читали, то вторая статья о том, как под python собрать dll и делать вызов функций, а не о качественной разработке программ на С…
1. Не хватает Readme с описанием проекта. Иначе, только провалившись в исходники, можно понять, что это свой игровой движок для шашек, домино и т.п.
2. Проект видимо живет очень очень давно, поскольку нет системы сборки, это же чудовищно неудобно оперировать десятками файлов. Также нет и намека на es6 и выше, а в вашем движке, думаю, это сильно бы упростило жизнь.
3. В html не хватает doctype (без него браузеры работают в quirk mode). Inline стилей в html лучше избегать, также как избегать абсолютных размеров вида 411px.
Думаю, если порефакторить код, сделать его читаемым, расширяемым, прикрутить webpack, дополнить документацией, то у вас выйдет очень популярный проект.
Зависит от компетентности разработчика. Хороший разработчик способен писать читаемый, понятный, «чистый» код.
Порой сама среда разработки способна подсказать тип на основе синтаксического анализа. Также помогает jsdoc и принципы контрактного программирования. Если уж совсем хочется typesafety, то TypeScript ваш вариант.
В мире js используется кооперативная многозадачность. И по опыту скажу, что для простых задач это лучше вытесняющей многозадачности (aka многопоточность), где с синхронизацией (мьютексы, атомики, happens before, видимость памяти) можно голову сломать.
Все верно, для этого в спеку ввели синтаксис async / await, который позволяет писать код последовательно:
В заключении скажу, js не идеален, никто с этим не спорит. Но язык развивается, совершенствуется, и думаю, он еще нас приятно удивит.
Оно конечно, как и все в реальном мире. Но оно (количество) изменчиво.
Я привел вам простой пример о функциях массивов и строк в php. Их более двух сотен. Нужно ли помнить их все? Используются ли они все в реальной жизни? Помните ли и используете ли вы их сами?
Принцип Парето никто не отменял: в разработке в 80% случаев используется 20% функционала ЯП / фреймворка.
Не надо в крайности бросаться. Я лишь акцентирую внимание на необходимой достаточности знаний.
Все верно, нужны исключения уровня приложения, и мои тезисы не противоречат этому. Разница лишь в том, делать ли ваш AppException checked или unchecked?
Сделав его checked, вы обязаны обрабатывать свои исключения или прокидывать выше. Это хорошо работает на небольшой кодовой базе. Но когда у вас тысячи классов с сотней методов, то выясняется, что ВСЕ они throws AppException. А потом еще выясняется, что в подавляющем большинстве методов идет простая обертка исключений вида:
Удобно ли это при разработке? Стоит ли надуманное разделение checked / unchecked такого шаблонного кода? Кроме того, checked исключения вы не сможете использовать внутри стримов (stream api), а это явное упущение.
Как я и упомянул, многие фреймворки (тот же spring) перешли на unchecked исключения уровня приложения, и в этом я с ними солидарен.
Что тогда вы подразумеваете под словами знать функции?
В том же php банально для массивов и строк порядка сотен функций. Помнить их все поименно не имеет практического смысла. Больший смысл имеет знать, что есть те или иные группы функций для определенного случая.
Все должно быть регламентировано, иначе можно бесконечно долго доводить до «идеала».
Допустим, время отклика приложения было 10сек, вас это не устроило, вы оптимизировали работу и добились отклика в 1сек… а почему не 0,1сек… почему не 0,01сек? Где грань?
Не стоит судить так категорично. Невозможно знать всю стандартную библиотеку языка, т.к. языки развиваются, если только они не мертвые. Также невозможно знать все особенности всех библиотек и фреймворков для этого языка. Везде нужна своя мера, в этом суть.
В конечном счете значение имеет то, как, имея какое-то знание средств языка, ты сможешь решить ту или иную задачу и как сделаешь это эффективно… или условно эффективно, лишь бы заказчик был доволен.