То есть фактически только учёт на кассе должен быть 100% надёжным… ну и тогда с какого перепуго оно всё тормозит нещадно?
Не знаю, что у них там тормозит. В конце концов java сама программу не напишет — кто знает какой у них там код?
На Android всё нормально работает, идея тоже.
Значимое преимущество — предсказуемое время работы и потребление памяти. Для GUI — это важно.
Только enterprise это в основном не про GUI.
Нет. Как я уже сказал: ARC, «умные указатели» и «арены» (в C++), borrow checker (в Rust) решают подавляющее большинство проблем.
ну да, умные указатели, borrow checker. В каком-нибудь swift может быть. В С++ это не работает — т.к. нет единого интерфейса для взаимодействия библиотек.
А в Java их нет? Хотите сказать что никогда не получали документов, где фигурировали устаревшие данные или вообще данные от других людей?
Насколько я понимаю, это вообще не имеет отношение к перечисленным проблемам.
Просто то, что в C++ приведёт, скорее всего, к падению — в Java приведёт к неверным результатам. Скажем если у вас где-то в памяти табличка с какими-нибудь курсами валют, но при обновлении ссылку на неё забывают обновить. В C++ будет «висячая ссылка» и программа упадёт, а в Java — она даст невероные результаты. И тут уж я не знаю что лучше.
Что-то не очень понял. Если данные обновили(таблица мутабельная), то зачем обновлять ссылку? Если таблица иммутабельная, то что значит «обновили»? И да — С++ вообще всё что угодно может вернуть. И сегфолд это не то же самое что exception. Неожиданное завершение Java программы — недопустимо(речь о enterprise и серверах).
А вы никогда не редактировали Wikipedia? Или хотя бы просматривали? И не сравнимали это с тем, как работает, скажем, программа по заказу товара в IKEA? Думаете покуптели IKEA делают больше заказов в секунду, чем посетители Wikipedia — правок в базе Wikipedia?
Редактировал, вроде всё хорошо. Икеей не пользовался, что это должно мне показать?
Бизнес вначале нанимает условных «дешёвых индусов», которые порождают ад в коде… а потом уже поздно.
Такое бывает и часто. В чём Ваша мысль? Что не нужно нанимать индусов и всё будет хорошо? Это и так понятно, но в любом случае без ГЦ придётся потратить больше времени как на разработку, так и на поддержку. Без значимых преимуществ.
Вот и условные «индусы» пытающиеся решать задачу методом добавления случайных мутаций в код с последующим прогоном тестов — могут привести код на любом языке в невменяемое состояние. Просто код с GC (и, особенно, на Java) дольше сопротивляется, вот и всё.
Это правда, программы с GC «дольше сопротивляются». Однако, это не все его заслуги. Даже «идеальный код» с ГЦ проще писать и поддерживать по сравнению с «идеальным кодом» без него.
Не привносит. Всё, что нужно делать — не включать в вашу программу код написанный «индусами». Запускать их в другом процессе или вообще общаться по сети.
Мы сейчас не говорим о Вашем софте. Все уже поняли, что у Вас в принципе нет ошибок, и ГЦ лично Вам не нужен. Но в _любом_ другом софте на С++, написанным профессионалом любого уровня, неизбежно есть полный набор этих ошибок. Более того — чуть ли не половина уязвимостей ПО с ними связана.
Специалист Java обычно как минимум на дешевле специалиста С++. И бизнес готов переплачивать в замен на (относительную)надежность и скорость разработки и поддержки.
Будьте уверены, когда у вас килотонна взаимодействующих компонентов разного качества, и вам нужно срочно добавить/изменить функционал, последнее с чем Вы захотите столкнуться — это ub, повреждение данных, segfault, утечки и прочие радости, которые неизбежно приносит С++. А что в замен? Скорость? Низкое потребление оперативки?
В типичной для бизнеса модели взаимодействия, скорость практически всегда упирается в бд, а Java и так довольно быстрая. Стоимость оперативной памяти несравнимо меньше стоимости работы, тут даже говорить не о чем.
Не развивается, а только поддерживается. Не даром Java вытеснила его отовсюду, оставив только недобитый легаси.
Java не идеальный инструмент, но GC хорошо себя показывает, облегчая и удешевляя разработку и поддержку.
Вы не правы. GC защищает от массы довольно сложнообнаружимых ошибок, и позволяет разработчику освободится от постоянного ручного управления.
Конечно, есть техники, позволяющие значительно упростить и обезопасить язык и без гц, но пока гц самый простой и всеобъемлющий способ.
При этом оверхед не слишком большой для большинства случаев.
Ниша, где GC востребован — огромна. Это и простые скрипты, и сложная бизнес логика, которая за вменяемые деньги поддерживается и развивается разными разработчиками на протяжении десятилетий.
Я думал не стоит пояснять, что я говорю о корректности в рамках управления памятью. Конечно, это никак не защитит от нпе и прочих ошибок, не очень понимаю к чему Вы это написали.
То, что gc защищает от утечек, в моей практике очень даже подтверждается. Java программы довольно редко текут по памяти, хотя, конечно, такое случается. Но это не повод полностью отказываться от защиты.
Сегфолд это ещё хороший сценарий, гораздо опаснее когда повреждают существующие данные.
Главное, что позволяет достичь GC — это корректность. Для бизнеса не так важно, что приложение работает чуть медленнее и кушает чуть больше памяти. А вот если у приложения течёт память или ручное управление привело к сегфолду, или, не дай бог, к повреждению данных?
Все эти рассуждения о связанности имеют смысл только для полноценных объектов в понимании ООП. Т.е. с внутренним состоянием и ответственностью за него. Между тем маппинг практически всегда происходит между структурами(DTO, Entity), а не полноценными объектами. Так что нет никакой разницы — конструктор, метод или функция, никакой разницы здесь не будет.
И да — для полноценного объекта вытаскивать всё состояние наружу через геттеры это плохой подход, так делать нельзя.
Многословность Java всегда добавляет неудобств, множество. IDE конечно, помогает, но это не панацея. Да и читать сгенерированный код всё равно придется. Другой вопрос — насколько менее многословен Delphi?
Можно добавить прогрев JVM в тест по Java? Просто несколько прогонов теста подряд. У меня результаты такие:
0
15000
Finished in 0,705s
0
15000
Finished in 0,588s
0
15000
Finished in 0,425s
Скорее не навязывает ООП там, где оно не нужно(а оно редко где нужно).
Jwt тоже из коробки работает. Но вся работа по созданию токенов переехала в TokenEnhancer/TokenConverter(оба интерфейса реализует один класс + там есть downcast). А почему страшный сон, если не секрет?
Речь о кровавом энтерпрайзе, и 8ой версии java. Вообще сколько с этим работаю, убеждаюсь что Java довольно плохой вариант для энтерпрайза. Со всеми ее reflection-based технологиями, когда изменение одного модификатора доступа(убрали final), может полностью остановить работу, не вызывая каких-либо ошибок в compile-time. Отсутствие статических проверок — зло, от этого надо уходить.
Тот же ктор в котлине выглядит получше. А большой опыт на одном языке ничего о кругозоре сказать не может
Фильтры это сервлет апи
У меня как-раз работает. Т.к мне пришлось писать свою реализацию токенов, используя апи спринг security. Поэтому ответственно заявляю: апи плохое, сконструировано абы как, везде Object'ы, downcast'ы и просто плохой код. Такое ощущение что сами создатели пытаются действовать в обход апи, посмотрите как работает JwtTokenStorage.
У меня тоже проблем не было. Удивился когда появились. И не три года назад, а пару месяцев.
Адепт здесь только один, и это не я. То что вам чего-то от меня хочется — не мои проблемы. Я просто показываю что вы не знаете о чем говорите. И вы уже сто раз расписались в своем невежестве, товарищ Скриптуха Адептуха
Скриптуха это как-раз плюсы, с его темплейтами и инклудами. Вы не понимаете что пишите просто. Ничего никуда не кастуется, вы явно описываете связанный список и хотите от него рандомного доступа. Это глупость, видно что вы просто не знаете как работают алгоритмы в принципе, не только в хс или плюсах. Зато орете громче всех.
Это везде с минимальными телодвижениями. Тем более спринг не самый лучший инструмент, далеко(говорю как человек, который им постоянно пользуется).
Сервлеты устаревшие и кривые, мвц со старой поточной моделью, вебфлукс сырые и страшные(Java же). Спринг секьюрити тихий ужас. Сам di в спринге и тот кривой. Да и с кроссплатформенностью не все так однозначно. В основном она есть, но иногда разные jvm ведут себя по разному.
Так что думать что язык используют только потому что он хорош(или инструменты) — ошибка. Большую роль играет история, популярность языка. И я думаю что дельфи кровь подпортила именно политика компании, а никак не качество или "устарелость" языка.
На Android всё нормально работает, идея тоже.
Только enterprise это в основном не про GUI.
ну да, умные указатели, borrow checker. В каком-нибудь swift может быть. В С++ это не работает — т.к. нет единого интерфейса для взаимодействия библиотек.
Насколько я понимаю, это вообще не имеет отношение к перечисленным проблемам.
Что-то не очень понял. Если данные обновили(таблица мутабельная), то зачем обновлять ссылку? Если таблица иммутабельная, то что значит «обновили»? И да — С++ вообще всё что угодно может вернуть. И сегфолд это не то же самое что exception. Неожиданное завершение Java программы — недопустимо(речь о enterprise и серверах).
Такое бывает и часто. В чём Ваша мысль? Что не нужно нанимать индусов и всё будет хорошо? Это и так понятно, но в любом случае без ГЦ придётся потратить больше времени как на разработку, так и на поддержку. Без значимых преимуществ.
Это правда, программы с GC «дольше сопротивляются». Однако, это не все его заслуги. Даже «идеальный код» с ГЦ проще писать и поддерживать по сравнению с «идеальным кодом» без него.
Мы сейчас не говорим о Вашем софте. Все уже поняли, что у Вас в принципе нет ошибок, и ГЦ лично Вам не нужен. Но в _любом_ другом софте на С++, написанным профессионалом любого уровня, неизбежно есть полный набор этих ошибок. Более того — чуть ли не половина уязвимостей ПО с ними связана.
Специалист Java обычно как минимум на дешевле специалиста С++. И бизнес готов переплачивать в замен на (относительную)надежность и скорость разработки и поддержки.
Будьте уверены, когда у вас килотонна взаимодействующих компонентов разного качества, и вам нужно срочно добавить/изменить функционал, последнее с чем Вы захотите столкнуться — это ub, повреждение данных, segfault, утечки и прочие радости, которые неизбежно приносит С++. А что в замен? Скорость? Низкое потребление оперативки?
В типичной для бизнеса модели взаимодействия, скорость практически всегда упирается в бд, а Java и так довольно быстрая. Стоимость оперативной памяти несравнимо меньше стоимости работы, тут даже говорить не о чем.
Не развивается, а только поддерживается. Не даром Java вытеснила его отовсюду, оставив только недобитый легаси.
Java не идеальный инструмент, но GC хорошо себя показывает, облегчая и удешевляя разработку и поддержку.
Вы не правы. GC защищает от массы довольно сложнообнаружимых ошибок, и позволяет разработчику освободится от постоянного ручного управления.
Конечно, есть техники, позволяющие значительно упростить и обезопасить язык и без гц, но пока гц самый простой и всеобъемлющий способ.
При этом оверхед не слишком большой для большинства случаев.
Ниша, где GC востребован — огромна. Это и простые скрипты, и сложная бизнес логика, которая за вменяемые деньги поддерживается и развивается разными разработчиками на протяжении десятилетий.
Я думал не стоит пояснять, что я говорю о корректности в рамках управления памятью. Конечно, это никак не защитит от нпе и прочих ошибок, не очень понимаю к чему Вы это написали.
То, что gc защищает от утечек, в моей практике очень даже подтверждается. Java программы довольно редко текут по памяти, хотя, конечно, такое случается. Но это не повод полностью отказываться от защиты.
Сегфолд это ещё хороший сценарий, гораздо опаснее когда повреждают существующие данные.
И да — для полноценного объекта вытаскивать всё состояние наружу через геттеры это плохой подход, так делать нельзя.
0
15000
Finished in 0,705s
0
15000
Finished in 0,588s
0
15000
Finished in 0,425s
Точно, что-то я совсем забыл что в авто минус на кузове.
Легко детектируется это как? Блоки может и все исправны, обрыв где-то посередине. Но работать ни будет ни один.
Почему нет?
Адепт здесь только один, и это не я. То что вам чего-то от меня хочется — не мои проблемы. Я просто показываю что вы не знаете о чем говорите. И вы уже сто раз расписались в своем невежестве, товарищ Скриптуха Адептуха
Скриптуха это как-раз плюсы, с его темплейтами и инклудами. Вы не понимаете что пишите просто. Ничего никуда не кастуется, вы явно описываете связанный список и хотите от него рандомного доступа. Это глупость, видно что вы просто не знаете как работают алгоритмы в принципе, не только в хс или плюсах. Зато орете громче всех.
Это везде с минимальными телодвижениями. Тем более спринг не самый лучший инструмент, далеко(говорю как человек, который им постоянно пользуется).
Сервлеты устаревшие и кривые, мвц со старой поточной моделью, вебфлукс сырые и страшные(Java же). Спринг секьюрити тихий ужас. Сам di в спринге и тот кривой. Да и с кроссплатформенностью не все так однозначно. В основном она есть, но иногда разные jvm ведут себя по разному.
Так что думать что язык используют только потому что он хорош(или инструменты) — ошибка. Большую роль играет история, популярность языка. И я думаю что дельфи кровь подпортила именно политика компании, а никак не качество или "устарелость" языка.