Ниже - транскрипт беседы в на тему
href=http://www.livejournal.com/users/kirillk/5063.htm
между мной и
Кириллом
Мнения принимаются в ЖЖ
Kirill 29.12.20 15:34 слушай, а мне интересно твое мнение
http://www.livejournal.com/users/kirillk/5063.htm
Kirill 29.12.20 15:34 если есть времЯ, конечно
ppavel 29.12.20 15:37 общая идея: чел всегда найдет как загадить
изменяя семантику. Например, реализует toString,
возващающий радиограммы METAR на солярисе.
Перегрузка операторов тут не причем.
Аспекты: могу еще подкинуть transaction,
security. Идея хорошая, реализация (pointcut) не
внушает доверия.
Kirill 29.12.20 15:37 про то, что может загададить, это и так Ясно
ppavel 29.12.20 15:37 так почему перегруженные операторы на особом
положении?
Kirill 29.12.20 15:38 просто перегрузка оперторов, и аспекты только
эскалируют ситуацию
Kirill 29.12.20 15:38 а toString() - это часный случай
ppavel 29.12.20 15:39 путь "не дадим уродам написать плохой код" никуда
не ведет.
если введение перегрузки операторов не усложняет
язык - я за.
Сложи на Java пару Integer. развлечешься...
ppavel 29.12.20 15:40 никакой он не частный. Это вещь, по имени которой
программист делает предположение о семантике.
ровно тоже самое, что и с операторами. т.е. любой
метод, являющийся частью идиоматики языка,
обладает такими проблемами.
Kirill 29.12.20 15:53 Я не согласен что "никуда не ведет"
Kirill 29.12.20 15:53 пример Java с отсутвем всЯких хитрых перегрузок -
хороший пример
Kirill 29.12.20 15:54 все же это заставалЯет вещи делать более Явно
ppavel 29.12.20 15:55 еще раз, в чем разница между + и hash, equalsTo,
toString, size() (привет, кста.... .size(),
.length, перегрузка + в строке и т.п. радости
"простого языка")
Kirill 29.12.20 15:57 практически ни в чем, за исключением того, что
toString() это строка с разумным текстом, котораЯ
не ЯвлЯетсЯ частью синтаксиса Языка
Kirill 29.12.20 15:58 а если мы начинаем конструкции Языка
интерсептировать или как-то перегружать, то
возникают вопросы
ppavel 29.12.20 15:59 а вот нефиг операторы делать конструкциями языка,
тут и будет счастье
Kirill 29.12.20 15:59 о чем и речь
ppavel 29.12.20 16:00 так что хотим доказать? :) я грю, что перегрузка
операторов полезна, ты, вроде - что нет....
Kirill 29.12.20 16:02 лучше методы перегружать с осмысленным и именами,
а семантику синтаксических конструкций оставить в
покое, потому что они должны означать то, что они
должны означать
Kirill 29.12.20 16:02 if (a==b) должно быть понЯтно всегда и везде
Kirill 29.12.20 16:02 вот и чем Я грю
ppavel 29.12.20 16:05 подожди, Кирилл :) ты имеешь в виду, что когда ты
пишешь +, то это всегда должно быть сложение,
правильно? когда ты пишешь hash, то это не должно
менять видимое состояние объекта, так? и то и
другое - соглашения. Никто не заставит
программиста правильно писать hash. Давайте будем
последовательными - не дадим! + - такой же метод
как и hash.
Kirill 29.12.20 16:09 Я согласен с тем, что можно заимлементить hash
так, что "мама -- не горюй", ровно как и написать
программу пальцем левой ноги
ppavel 29.12.20 16:09 так чем '+' отличается от hash?!!!
ppavel 29.12.20 16:10 пиши плюс, чтобы всегда было сложение - и люди
пойдут за тобой :)
Kirill 29.12.20 16:10 всего лишь тем, повторюсь, что + ЯвлЯетсЯ частью
синтаксиса. хотЯ, в данном случае - hashCode()
ЯвлЯетсЯ частью Java так же как и +
ppavel 29.12.20 16:11 в чем принципиальная разница между "частью
синтаксиса" и "не частью синтаксиса"? давай
сделаем так, чтобы он не был частью синтаксиса и
разрешим перегружать, нормально будет?
Kirill 29.12.20 16:14 хорошо, на примере: соглашение о том, что "все
объекты передаютсЯ по ссылке" гораздо проще чем
"объект может передатьсЯ по ссылке, по значению,
причем вы можете заимлементить оператор
копированиЯ как захотите"
Kirill 29.12.20 16:15 в первом случае, если надо передать копию, будет
call(arg.clone())
Kirill 29.12.20 16:15 во втором текст не изменитсЯ
Kirill 29.12.20 16:15 просто в неком другом месте поЯвитсЯ
перегруженный оператор
Kirill 29.12.20 16:16 что вызывает тот самый эффект - что понЯть как
реально работает тот или иной if, или вызов
метода и что реально просиходит, нужно держать в
башке контекст нехилый
Kirill 29.12.20 16:16 если нет поддержку тулзы - то становитсЯ плохо
ppavel 29.12.20 16:17 стоп, это мы уже улезаем в семантику языка
(передача параметров). На такое расширение
дискуссии я сейчас не готов. Давай ограничимся
арифметическими операторами.
Kirill 29.12.20 16:18 то же самое - арифметические операции должны быть
уделом арифметических примитивных типов
Kirill 29.12.20 16:18 не фиг что попал с кем попало "складывать" и
перегружать это как попало
Kirill 29.12.20 16:18 потом фиг разберешсЯ
ppavel 29.12.20 16:19 Кирилл, мне кажется - это демагогия :)) в том
смысле, что как только у тебя кончаются
встроенные типы (вводятся длинные интегеры,
плавающие с расширенной точностью, вектора,
матрицы) - получаешь тоже самое. Т.е. + тебя
защищает только на встроенных типах.
в указанном тобой смысле любой полиморфизм
увеличивает контекст, но на практике это не так.
Кстати, встроенный + параметрически полиморфен -
его поведение зависит от типов. Тебе это мешает?
Kirill 29.12.20 16:21 длЯ матриц нужно не Java юзать а
специализированные тулзы
ppavel 29.12.20 16:22 операция сложения векторов определена не хуже,
чем integer ов. См. выше про целые числа с
неограниченной точностью. чем они хуже целых?
привет от бухгалтеров... а еще натуральные
дроби....
int a=1, b=3, c=3.0;
a/b;
a/c;
? параметрический полиморфизьм, однако....
ppavel 29.12.20 16:22 очень умно :) почему? (подумай об усложнении
управления конфигурацией)
ppavel 29.12.20 16:22 ... и о доступности тулзов на различных
платформах....
Kirill 29.12.20 16:24 ради математики не стоит портить простоту Языка.
что до + -- менЯ вполне устраивает что он
полиморфен длЯ строк и примтивных типов
Kirill 29.12.20 16:24 а длЯ остальных он неприменим
ppavel 29.12.20 16:25 кирилл, ну бухгалтерия же :))) в java нет
<встроенного> типа fixed precision real. Проблема
как раз в сложности Java, ее перегруженности
синтаксисом
ppavel 29.12.20 16:25 Кирилл, вдохни, сделай паузу и подумай еще раз
про применимость + ;)))
честно :)
мне можно не признаваться :)
Kirill 29.12.20 16:26 мне уже года 2 назад писатели мат софта долго
доказывали что Язык базе перегрузки операторов -
не Язык
ppavel 29.12.20 16:26 как раз в случае со строками - он бредовый :) я
ожидаю от + коммутативности, как минимум :))
вообще алгебраической группы ожидаю.... а что
имею? строки образуют моноид. В Smalltalk строки
(как и любые SequenceableCollection) склеиваются
','
ppavel 29.12.20 16:26 бухгалтерия, кирилл!! :)))
Kirill 29.12.20 16:33 хорошо, Я думаю что Язык общего назначениЯ как
Java не подходит длЯ бухгалтерии, а точнее -- длЯ
программеров, которым не хватает float
Kirill 29.12.20 16:33 с дробЯми - не знаю
Kirill 29.12.20 16:33 в смысле - с натуральными
ppavel 29.12.20 16:34 круто.
я повешу объявление: "Кирилл Калишев из JetBrains
считает, что Java не подходит для бухгалтерии и
финансовых систем!"
Можно? :))
ppavel 29.12.20 16:34 а для чего он тогда подходит? для изготовления
средств разработки на Java ? :)))))
Kirill 29.12.20 16:35 ...длЯ программеров, которым не хватает float
Kirill 29.12.20 16:35 Я не понимаю почему не хватает примтивных типов
длЯ бхгалтерии
Kirill 29.12.20 16:37 кстати, а какой Язык лучше подходит?
ppavel 29.12.20 16:42 1. Примитивных типов для бухгалтерии не хватает
потому что требуются дроби с фиксированной
точкой. вычисления с float и double крайне
неустойчивы (в вычислительном смысле). т.е.
вычитание двух больших близких float может
создавать ооочень большие ошибки. Читайте
Фаулера, например :)) вообще, все, кто считал
большие деньги обязаны это знать
2. хорошо подходит то, что может использовать
типы, описанные выше и при этом остается
приличным языком :))
ppavel 29.12.20 16:43 для 2D и 3D геометрии java тоже не подходит, если
следовать такой логики - с векторами не
разбегаешься :))
Kirill 29.12.20 16:45 все зависит от вычислений, если в двух местах
программы вместо vector1 + vector1 нужно писать
vector1.add(vector2) то это не причина
Kirill 29.12.20 16:45 вообще, выходов можно много придумать
Kirill 29.12.20 16:46 хоть кодировать все формулы бухгалтерские во во
внешнем ресурсе и там как-то вычислЯть
Kirill 29.12.20 16:46 все зависит от задачи, Я не думаю что проблема
столь уж велика
ppavel 29.12.20 16:47 а представь алогритм вычисления среднего над
коллекцией... тебе дорогой придется их две копии
написать - для векторов и для примитивных чисел
(это с generics). А то и больше.....
Kirill 29.12.20 16:47 это проблема эффективного in-boxing'a и ничего
общего с Языком не имеет, оп моему
ppavel 29.12.20 16:48 это неудобно. Очень. Ты ломаешь ход
программирования. Ну бред же, согласись... а
рефакторинг над внешними ресурсами?
проблема из разряда невеликих, но неприятных. В
Smalltalk другая проблема - отсутствие
приоритетов операторов. Так вот к ней привыкаешь
легче - единообразие, черт побери....
ppavel 29.12.20 16:50 погоди, проблема полиморфизма по векторам и
примитивным типам - проблема эффективного
инбоксинга? т.е. все примитивы боксятся и везде,
где ты хотел написать + ты пишешь add() ?
нуууууу.... нафиг вообще операторы ? лисп форева?
Kirill 29.12.20 16:51 какой рефакторинг у формулы? как раз не бред
ppavel 29.12.20 16:54 (monthlyFees + monthlyDeduction) * months =>
pureMonthlyFees() * months
Kirill 29.12.20 16:56 Я думал что ты иммем в виду рафторинг кода,
который затрагивает формулу
Kirill 29.12.20 16:57 вроде как переименование класса затрагивает его
декаларцию в xml
Kirill 29.12.20 16:57 ну, а что, в чем проблема чтобы так формулу
зарефакторить?
Kirill 29.12.20 16:57 короче, мы в тупик пока зашли :)
Kirill 29.12.20 16:57 нужно очно перетереть
Kirill 29.12.20 16:57 как нибудь, при случае
Kirill 29.12.20 16:58 но за мнение - спасибо
ppavel 29.12.20 16:58 вот тебе еще примерчиков:
комплексные числа (вся радиотехника)
метачисла (бесконечности - правая и левая,
научные рассчеты)
ppavel 29.12.20 16:58 пжалста :) можно публиковать транскрипт? :)
Kirill 29.12.20 16:59 вычислениЯ - все понЯтно, тут нужно думать
конкретно а не демагогию разводить, и, возможно,
все же юзать не просто plain java
Kirill 29.12.20 17:00 Я в своем посте и оговорилсЯ про вычислениЯ
ppavel 29.12.20 17:00 давай я сформулирую свое мнение:
если проблемы в предметных областях вызваны
артефактами проектирования языка - тем хуже для
языка.
ppavel 29.12.20 17:02 hint: операторы в подавляющем большинстве
используются для организации вычислений. т.е. я
готов мириться со всем, кроме арифметических
операторов. Т.е. с ними я тоже готов мириться,
но.... это уже становится неприятно. Особенно,
когда дело доходит до того, что в зависимости от
диапазона чисел я должен писать разный код.
Kirill 29.12.20 17:02 не понЯл: проблемы в выражении предметной области
средствами Языка?
ppavel 29.12.20 17:03 проблема java по отношению к предметным областям:
при обработке длинных, комплексных, расширенных
чисел приходится переходить к другому синтаксису.
Смешивать нельзя. примеры областей: финансовые,
статистические, научные, инженерные вычисления,
аналитическая геометрия.
ppavel 29.12.20 17:04 кстати, еще раз подтверждается забавное
наблюдение, что smalltalk еры постоянно тупят,
когда народ из java лагеря заводит разговоры о
доменных языках и кодогенерации :)
ppavel 29.12.20 17:05 так мона публиковать? я бы тоже мнением народа
поинтересовался.... именно по приводимым
аргументам....
Kirill 29.12.20 17:05 я думаю что длЯ организации сложных вычислений
Java не подходит, другое дело - где граница этой
сложности. „умаю, что когда это действительно
стнавитсЯ сложно, то нужны препроцессоры,
кодогенераторы и т.д.
