Pull to refresh

Comments 83

Как-то желто. Java остается, MySQL остается, VirtualBox остается, может еще что-то, особо не разбирался что входило в Sun на момент покупки. Только Solaris и Co перестают развивать, давно к этому шло, мало кто делает новые решения на базе Solaris.
UFO just landed and posted this here

Т.е. то, что будет в Java 9 и делается для Java 10 — не считается? Или, быть может, вы считаете, что в OpenJDK Оракл почти не контрибьютит?

Сравните то, что есть/будет в java 9 и то, что уже есть в C#. Java как язык замер в развитии, и постепенно сдает позиции.
UFO just landed and posted this here
В чем примущество отсуствия сахара? Зачем жертвовать удобством написания и читания кода?
Ни в одном современном языке не приходиться писать:
balance.setSaldoOut(balance.getSaldoIn().add(balance.getNach()).subtract(balance.getPayment()));

вместо простого и понятного:
balance.saldoOut = balance.saldoIn + balance.nach - balance.payment;

UFO just landed and posted this here
UFO just landed and posted this here
Ну да, еще про оператор var из C# забыли. Очень удобно писать SomeBigNameOfClass result = new SomeBigNameOfClass();

По факту тогда, в чем смысл криков про лямбды и больше новых фич в новых версиях? Все же можно через сторонние либы сделать или, как вы сказали, добавить обработку типа в JVM.
Только вот ни того ни другого в Java нет, а во всех современных языках есть.
Дополнительно из-за отсутствия сахара для свойств в java, в случая любых ограничений (not null/not negative) на поля приходиться постоянно использовать get/set
UFO just landed and posted this here
Писать код вида #define true (Math.random()>0.5) все равно не запретишь. Сейчас это можно размешать внутри equals и радоваться странным результатам. Это не та проблема с которой нужно бороться.

Оператор "==", типы в коллекциях java иммеет много больных мест и при нынешнем ходе развития они никогда не исправяться и не будут исправляться, чтобы не ломать совместимость.
UFO just landed and posted this here
Я понимаю, что изменить поведение "==" уже не получиться, но можно хотя бы ввести "===" на сравнение по значению. Это не ломает совместимость. В js уже так поступили.
Не дай бог. Не нужно в Java этого костыля, пусть остается в JS.
Костыль это Object.equals(a,b) не удобный в использованию и не работающий к тому же для чисел.
Метод в объектно-ориентированном языке не может быть костылем по определению ) Вот === вполне. И ради чего, чтоб Java был больше похож на JS? Да сами JS разработчики не в восторге от ==/===, а вы предлагаете его еще и перенести в язык без этого костыля. Не нужно.
В js используется == в java же он очень редкий зверь годный только для примитивов. Единообразие в синтаксисе сильно повысит читаемость. А предупреждения при компиляции помогут избегать ошибок. Можно же попросить явно аннотировать места где используется именно сравнение по ссылке.
Мне лично кажется, что при соревнованиях между скоростью разработки и православностью синтаксиса в долгосрочной перспективе при прочих равных всегда выигрывает скорость разработки. Поэтому лично мне кажется, что упарываться чистотой белой расы синтаксиса — это путь в никуда.
Почему вы пытаетесь использовать объектно-ориентурованную Java как процедурный ЯП? По хорошему, ваш пример на Java должен выглядеть так:
balance.recountSaldoOut();

и реализовываться так:
public recountSaldoOut(){
  saldoOut = saldoIn + nach - payment;
}
Так писать на Java не получиться. Максимум выйдет следующее
public recountSaldoOut(){
	saldoOut = saldoIn.add(nach).subtract(payment);
}

Плюс подобное работает только если работаем с одним объектом. Если входных объектов несколько и есть еще выходной, то данный подход не сработает.
Так писать на Java не получиться

Ну это зависит от типа saldoIn, nach и payment.

Если входных объектов несколько и есть еще выходной, то данный подход не сработает

Почему? Можно ведь всегда указать зависимости, в том числе функциональные, на пример так:
public getSaldoOut(nach, payment){
  return saldoIn.add(nach.getValue() - payment.getPaid());
}
UFO just landed and posted this here
double для финасовых приложений не пригоден. Везде надо использовать BigDecimal, чтобы хотя бы сложение/вычитание работало с абсолютной точностью. Класс же BigDecimal использовать для арифметики не удобно. Простое сравнение с нулем выглядит так
public boolean isZero(BigDecimal val) {
        return BigDecimal.ZERO.compareTo(val) == 0;
}
UFO just landed and posted this here
Название balance уже само собой подразумевает финансы) Где альтернатив просто нет.
UFO just landed and posted this here
Ксчастью вам не приходилось постоянно ковыряться в многостраничных текстах арифмитических операций, которые трудно читаемых в любых случаях чуть более отличных от тривиальных.
На самом деле, можна записать ваш код короче, использовав метод signum()
return val.signum() ==0;
Соглашусь на 80%

Добавлю, что объекты все равно создаются. А запись ссылки в переменную — не overhead (не факт что будет). И в более сложных случаях можно сделать запись в несколько строк, давая осмысленные имена получаемым сущностям.

Но syntax sugar все же удобен.
Но syntax sugar все же удобен

Проблема syntax sugar в том, что он делает кривую обучения более крутой. Для понимания работы кода, необходимо понимать не только базовые операторы языка, но и особенности реализации «сахара».

Это особенно заметно в проектах, без стандартизации формата кода и с большим числом разработчиков. Кодовая база быстро делится на блоки, с которыми работают только те разработчики, которые знакомы с используемым в этом блоке «сахаром». На практике это выглядит примерно так: «в проект пришел джун, запилил реализацию на каком нибудь модном сахаре, после чего покинул проект, и реализацию либо переписали, либо все бояться ее трогать».
На изучение возможностей сахара требуется ничтожное количество времени. Вот чтобы изучить, сконфигурировать и настроить простейший сервер, требуется на порядки больше времени и усилий, чем на изучения скажем множественного возврата.
Это от человека зависит, сколько ему времени требуется для изучения сахара, а если это группа человек, то времени требуется еще больше, и все для того, чтобы джуниор мог попробовать в проекте новый «сахар». Такая себе плата за «сахар», заменяющий add() на +
На понимание, что в отличие от других языков здесь надо складывать через add(), а не через + уходит как бы не больше времени.

В целом вопрос не был бы столь болезненным, если всего для одного! стандартного класса определили бы арифметические операции.
На понимание, что в отличие от других языков здесь надо складывать через add(), а не через + уходит как бы не больше времени

Повторюсь: это зависит от типа. Если вы работаете с примитивами, они прекрасно поддаются сложению с использованием математических операторов, но если вы пишете свой тип (класс), то придерживайтесь объектной нотации — операции над объектами это методы. Любой разработчик на java это понимает сразу. На понимание смеси процедурного и объектно-ориентированного кода уходит больше времени просто потому, что это два подхода, а не один, что, априори, требует больше знаний.

В целом вопрос не был бы столь болезненным, если всего для одного! стандартного класса определили бы арифметические операции.

Возможность перегрузки математических операторов спорна, так как применима далеко не к любому типу чисто семантически, а методы, в свою очередь, позволяют отразить операцию максимально приближенно семантически к домену.
Вся боль, что так как Java это в первую очередь финансовые системы, а все расчеты для них ведутся через стандартный BigDecimal. Работать с остальными примитивами нельзя.
А именно для этого стандартного класса нет удобного способа работы. В итоге приходиться писать все арифметические операции словами.
Потому я вам сразу и сказал: работая с объектно-ориентированным языком, придерживайтесь объектно-ориентированной нотации. Математические операторы это не объектно-ориентированная нотация, потому ее и нет в Java.
Аттрибуты вписываются в концепцию объектно-ориентированная нотации?
Если они инкапсулированы. По сути, атрибуты (я предпочитаю термин — свойства) не видны снаружи, потому их семантически не существует, вы оперируете объектами и методами, а не переменными, данными и операциями над ними. В этом и отличие объектной нотации от процедурной.

Т.е. я прописываю классу атрибут Controller, кардинально меняю его поведение, считай, наследуюсь от другого класса и это все вписывается в объектно-ориентированную нотацию?

Вы под атрибутом понимаете «аннотацию» или «метаданные»? Если так, то это уже не объектно-ориентированная нотация, а декларативная.
Вместо того, чтобы решить проблему, вы предлогаете постоянно бороться с плохим дизайном языка, не предусмотревшем арифметических операций.
Почему вы решили, что если у другого ЯПа непривычный для вас дизайн, то это плохой дизайн? Вы давно занимаетесь разработкой? Вы знакомы более чем с 1 ЯПом?

Если вы привыкли к математическим операторам и процедурному подходу, возможно вам стоит использовать язык, который под это лучше заточен, а не Java, которая является объектно-ориентированным языком.
Я из хожу из простого наблюдения, что один и тот же код написаный на js и на java. Читаем на стороне фронта, а вот на стороне сервера вызывает затруднения. К сожалению просто поменять язык сервера нельзя.
К тому же совершенно не понятно, почему для базовой сущности нельзя сделать исключение. Как ниже заметили для строки же это сделали.
К сожалению просто поменять язык сервера нельзя.

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

К тому же совершенно не понятно, почему для базовой сущности нельзя сделать исключение

Тоже задаюсь этим вопросом.
Для стринга же определили ;)
В чем примущество отсуствия сахара?

Диабетики не страдают.

Кроме непосредственно Джавы есть ещё jvm, на которой работает ещё куча языков с кучей фич. Код на этих языках можно положить прямо в тот же проект, что и код на джаве. Так что те, кто желает сахара — без проблем могут его получить.

UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Того же JPA несчастного

А что там не так то? Цепляем обычный драйвер, поверх накатываем ORM by Hibernate. Все, не паримся, «оно работает».
UFO just landed and posted this here
что мой запрос не нужно будет полностью переделывать в случае перехода на другую ORM.

Не, если у вас это не сфероконные вопросы/ситуации, а вот прям реально на горизонте указанно, что «скоро будем менять подсистему ORM с X на Y», тогда да, возможно этим вопросом надо так же озадачиться.

Однако, на моей памяти не было такого, что по непонятным причинам меняется сама ORM. Во-вторых, сама ORM нужна для чего? Чтобы можно было безболезненно менять саму type-of-database (скажем типично с MySQL на PostgreSQL). То, что вам при этом можно без любых правок менять саму ORM — никто и нигде не обещает (ибо в требования к ORM вообще ни разу не входит).

P.S. Я в своих суждениях отталкиваюсь именно от интересов бизнеса, а не от академических «а что, если...». Ибо постановка ситуации мне видится притянутой за уши.
UFO just landed and posted this here
Так что кейс вполне реальный D:

чем планировали при постановке ТЗ.

В моем мире это означает «раз заказчик ТЗ нарушил, то вот ему штраф, и, что еще приятней — я могу забить на сроки» — волос не теряем. К тому же, ну как-то странно, на мой взгляд гибер будет де-факто-стандарт.
Впрочем то, что вы смогли решить задачу, это делает вам честь безусловно. С этим я согласен. Но бить дилдо по голове таких фруктов, что так ломают ТЗ.
Что касается авторизации — а в чем проблема то сделать стандартными средствами? Ок, поясню — у нас два варианта входа (авторизации). Пишем один код для веба, другой для 1С. Далее, делаем простейшую единую и универсальную точку входа, уже внутри которой мы сможем определить каким маршрутом делать авторизацию. Это все справедливо, если тащить спринги нет желания (читаем как делаю свой детский велик).

UPD: Про дилдо — если за эти безобразия клиент все же платит адекватно и понимает о сдвиге сроков, то сей агрегат будет уже излишним ;)
Android перешел на Kotlin, это большой камень в огород Java
Android не «перешёл на Котлин», а теперь поддерживает ещё и Котлин.
Извиняюсь за неточную формулировку. Добавил поддержку, камушек в огород Java :)
в огород Java, которая является основой для Котлин?
А архитектура SPARC? Это же большой кусок истории (да и сейчас например Fujitsu делает спарки)
Это в Co, т.к. Solaris на x86 был, но все-таки больше для SPARC. Большой кусок истории — да, но сам Оракл не видит как это сейчас можно продавать.

Он давно развивается в рамках OpenZFS под разные популярные ОС (линукс, фряха, иллюмос)

Разработчики ZFS ушли в опенсорсный illumos очень скоро после закрытия OpenSolaris. Там же и развивали, а дальше код уже остальные растащили, в том числе Linux.

А она разве использовалась достаточно широко?
С некоторых пор есть более свободная BTRFS, которая повторяет многие фичи из ZFS. Полагаю, ZFS сегодня не слишком-то нужна. Хотя году в 2009 она казалась интересной.

ZFS — старая проверенная ФС (в целом, линукс-реализация молода и не всё поддерживает, насколько я помню), а вот BTRFS пока еще очень молодая, все её тестируют только, а воз и ныне там.
Ввиду недавнего решения Red Hat будущее BTRFS уже слегка как бы под вопросом. Посмотрим. Надеюсь выживет и будет развиваться, альтернативы и здоровая конкуренция — это классно.
Нет. SUSE и далее продолжит развивать и поддерживать BTRFS, а решения RH ничего не решают.
image
Zones

А напомните мне пожалуйста, Sun первыми их придумали, потом оно уже перетекло в FreeBSD Jail? Гугл что то не помог

Скорее всего наоборот. Они развили идею BSD Jails, довели ее до завершения.

Никак не смог нагуглить год появления BSD Jails. Зоны в соляре появились в 2005 для Solaris 10, если верить вики.
UFO just landed and posted this here
Jail во FreeBSD был в то время небольшим патчем сетевой подсистемы для функционала chroot, а chroot существовал с незапамятным времен. В то время в соляре уже был менеджер ресурсов (память, CPU) для приложений, чего в джейлах нет до сих пор. Конечно, какие-то идеи они позаимствовали из джейла, какие-то — из эмулятора (сисколлов) линукса
Как-то так сложилось, что лично для меня Oracle — непонятная компания. Для обычного рынка у нее вообще никаких решений нет. Для крупного бизнеса у нее есть БД с заоблачными ценами, от которой все по мере возможности пытаются убежать (хоть взять Яндекс, который недавно писал, как они с Oracle переехали на PostgeSQL) и всякие большие системы управлением бизнесом, все известные мне пользователи которой плюются и матерятся. Java, SPARC, Solaris и прочее — это все-таки наследие Sun, которое Oracle успешно продолбала.

Поэтому от этого Oracle лично у меня ни в голове, ни в жопе. Развались он хоть завтра, даже поностальгировать будет не о чем.
У Oracle, на мой взгляд, только один нормальный продукт — это собственно их СУБД и кластерное ПО для неё (Solaris не считаю, т.к. это их продукт, пришедший извне). Всё остальное, что доводилось администрировать, требует недюжинной выдержки и постоянного копания в десятках разрозненных конфигов и мутных мануалах.
Зато сама СУБД — космос, полностью компенсирует недостатки остального Оракловского софта. :)
Эх, поднажать бы ещё на Postgre. И забудут все про Oracle.
Sign up to leave a comment.

Articles