Начал играть недавно с Julia и имхо реально бомба. Версия >1.0 и народ проникся, в МIT вроде на ней уже студней учат.
1) Пишется быстро. Питон не нужен.
2) Работает быстро, а если приложить руки, то очень быстро. C++ не нужен.
3) Компилирует быстро. Скала не нужен.
4) Доки — супер, репл — супер, jupyter kernel — супер.
5) Макросы и multiple dispatch, соответственно ООП выкинули. Clojure не нужен.
6) Очень крутой интероп не только с С, но и с питоном.
Из недостатков:
а) сложно со встройкой, очень большая. Lua нужен.
б) нет js-backend, но это наверное сделают.
c) Индексация массивов с 1. Гребанный матлаб.
Здравствуйте, novitk, Вы писали:
N>Начал играть недавно с Julia и имхо реально бомба. Версия >1.0 и народ проникся, в МIT вроде на ней уже студней учат.
Мы пытались использовать её для наших задач — симуляции электросхем и computer vision/ml.
Пока что вердикт: "Негодно, но стоит проверить ещё через пару лет".
Проблемы:
1. Компилятор таки достаточно небыстрый на больших объёмах, особенно при холодном старте.
2. Плохой менеджмент потоков и памяти. Там свой планировщик задач на libuv, но работает он пока что посредственно.
3. У нас оно часто падало в Jupyter'е, требуя перезапуска ядра.
Но само плохое — это отсутствие библиотек. Не хватает тонн вещей, особенно в области Machine Learning.
По скорости получилось на порядок лучше Питона, но в несколько раз медленнее кода на С++.
Здравствуйте, Ikemefula, Вы писали:
I>ООП выкинули — значит, что пишут только мелкие скриптики в repl или узкоспециализированые утилиты. Как только начнут писать тяжелые многофункциональные приложения, или ООП вернётся само собой, или язык останется в нише.
На lisp/clojure нет многофункциональные приложения?
Ты еще не в курсе, что классический ООП с мьютабильностью и single-dispatch это анти-паттерн?
Здравствуйте, Mr.Delphist, Вы писали:
MD> Вопрос: почему другие языки не дают пользовательскую базу для индекса массивов? Инерция мышления?
Во-первых, накой оно? На практике голые массивы по индексу вообще редко нужны. Чаще списки, мапы, деревья, в худшем случае буфер (т.е. именно что memory layout). Обход по foreach.
Во-вторых, это можно юзабельным сделать только при хорошей системе типов. Ну, допустим, есть у тебя массив [-10..10]. И тебе надо иметь функцию поиска макс эл-та в списке. Зачем этой функции два индекса? Или где-то магически переиндексироваться должно? В рантайме, с накладными расходами? Или компилятор должен это как-то магически перекодировать?
В-третьих, зачем это встраивать в язык? Написать класс, который инкапсулирует обычный массив и shift — плёвое дело на любом современном языке.
В-четвёртых, KISS.
Здравствуйте, Sharov, Вы писали:
I>>В веб приложении все хором пилят, например, Роутер, что снова есть частный случай всем известного паттерна GOF.
S>Можно подробнее, что за паттерн? Команда или стратегия ?
Chain of responsibility, он же роутер, он же конвейер(pipeline). Decorator, он же мидлвара, это транзитивный обработчик, например, подтягивает аутентификацию, парсинг, и тд., промежуточный процессинг. Команда — это обычно терминальный обработчик.
Все эти вещи будут независимо от парадигмы. Роль собтсвенно парадигмы — перевод конкретного решения в код. То есть, сначала решили задачу, а уже потом перевели в код. Паттерны являются готовым вариантом этого вот перевода. Потому очено смешно, когда товарищи функционалисты воюют с ооп, но при этом вовсю используют роутеры, мидлвары и тд
Здравствуйте, novitk, Вы писали:
I>>ООП выкинули — значит, что пишут только мелкие скриптики в repl или узкоспециализированые утилиты. Как только начнут писать тяжелые многофункциональные приложения, или ООП вернётся само собой, или язык останется в нише.
N>На lisp/clojure нет многофункциональные приложения?
Браво — ты решил соскочить с Julia на lisp, clojure. И там, и там такие приложения за пределами статической погрешности. Можно пренебречь.
N>Ты еще не в курсе, что классический ООП с мьютабильностью и single-dispatch это анти-паттерн?
ООП не имеет отношения к мутабельности и иммутабельности. Эта парадигма целиком вся не летает. Для неё нужен нижележащий слой — императивное (С++, C#, Java), функциональное (F#, Ocaml, Scala), реактивное, логическое программирование и тд. Т.е. ООП всегда живет на другой парадигме, т.к. отвечает не за вычисления, а за структуру решения. Например: агрегирование, делегирование, композиция, типы-подтипы, модули. Вот за это отвечает ООП.
Хочешь использовать иммутабельность с ООП — пожалуйтса. Эту иммутабельность придумали несколько тысяч лет назад для ведения бухгалтерских книг. С чего бы в ООП было запрещено использовать такую древнюю вещь?
Про сингл-диспатч смешно — 99% приложений писалось и по сей день пишется именно в таких языках.
Мультидиспач может совмещаться и с ООП, принципиальных проблем нет. Проблемы в самом мультидиспаче — это пока достаточно непопулярная вещь. Например, мультиметод можно добавить в модуль. Так? Тут надо вспомнить, что класс в ООП это тип + модуль. Экземпляр в ООП это снова тип + модуль. Итого — всё в порядке в ООП мультидиспачем.
Здравствуйте, novitk, Вы писали:
C>>Проблемы: C>>1. Компилятор таки достаточно небыстрый на больших объёмах, особенно при холодном старте. N>Холодный старт до сих пор плохой, но народ говорит, что Revise.jl купирует проблему.
Пока не пробовали, но отсутствие настоящего компилятора напрягает.
C>>2. Плохой менеджмент потоков и памяти. Там свой планировщик задач на libuv, но работает он пока что посредственно. N> C>>3. У нас оно часто падало в Jupyter'е, требуя перезапуска ядра. N>По слухам вроде сессии живут неделями.
Баги где-то в рантайме. У нас достаточно сложный многопоточный код.
Но это не фундаментальные проблемы, а просто болезни роста. Потому и вердикт — посмотреть чуть позднее.
C>>Но само плохое — это отсутствие библиотек. Не хватает тонн вещей, особенно в области Machine Learning. N>Да, это фигово. Однако PyCall мне очень понравился, то есть переползать можно плавно. N>На днях хочу попробовать TF враппер: https://github.com/malmaud/TensorFlow.jl
Как-то слишком громоздко. Уж лучше тогда всё на Питоне писать, а на Julia только новые вещи.
Здравствуйте, student__, Вы писали:
N>>Начал играть __>Там уже можно сделать заранее откомпилированный бинарь программы без траходрома (не сильно сложнее, "cmake . && make")? Иначе "убийства" С++ и Fortran так и не состоялось.
Сейчас весь новомодный Machine Learning живёт, фактически, на 100% в Питоне. Где траходрома с установкой столько, что даже ./configure на снилось. В основном из-за того, что Питон используется как обёртка над библиотеками на чём попало.
Julia тут как раз больше подходит из-за того, что на ней можно писать без использования С/C++, и оно будет достаточно быстро.
Здравствуйте, BrainSlug, Вы писали:
N>>1) Пишется быстро. Питон не нужен. BS>библиотек нет многих, что есть на питоне, или на том же R
Да, но с Питоном интероп очень хороший, это вполне себе вариант для "неосновных" библиотек. Для основных типа tf, pandas, numpy варианты вроде есть. Понятно, что они отстают, но если язык станет популярен, это все чинится.
BS>коммон, джулия убийца c++, это даже несмешно
Для системных целей конечно нет, но в матмоделировании вполне.
BS>вот уж не ожидал здесь скалу увидеть. когда у скалы преимущество в скорости компиляции появилось?
Имеется ввиду, что скалу не дождешься.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, AlexRK, Вы писали:
ARK>>Так это ж наоборот круто. CC>Шоп да так ж нет!
Кстати, вот удивляло: в Паскале самых ранних версий (т.е. даже не Delphi ещё) можно было делать индексы хоть отрицательными, хоть как. Просто пишешь "x: array[-10..10] of integer" и готово, получаешь массив на 21 элемент. Таким образом, индексацию можно было получить согласно задаче, а не исходя из memory layout, как это традиционно делается.
Вопрос: почему другие языки не дают пользовательскую базу для индекса массивов? Инерция мышления?
Здравствуйте, Ikemefula, Вы писали:
I>Вероятно, для тебя ООП это три кита. На самом деле это необязательная модель. Вот например есть у тебя логирование — это уже ООП. Даже если ты его монадой writer реализуешь, всё равно это будет ООП.
ООП — это таки весь стиль программирования. Т.е. сокрытие реализации, доступ к внутренним данным объектов через методы, наследование реализации и т.п. Это всё, к счастью, начинает умирать. Даже в самых ударенных на ООП-голову языках как Java.
Элементы ООП оказались полезны, да. Но практически это только интерфейсы и группировка функций в виде методов классов.
Здравствуйте, Cyberax, Вы писали:
C>>>Большую часть этого всего выбросили в Go. И ничего. Живёт так, что скоро Java начнёт теснить. С>>Оно теснит скорее скрипты на bash и perl. C>Kubernetes — 1.5 миллиона строк.
Строк на Го. Т.е. на нормальных языках полторы тыщи будет.
Здравствуйте, vdimas, Вы писали:
V>Мной лишь озвучено вслух, а дано самой спецификой задачи.
Какой задачи? Цитату плз.
V>Мы всё еще говорим об оптимизации арифметических операций?
Не знаю о чём говорите вы, но я об этом даже не начинал говорить.
V>Я отвечал на кое-какое твоё конкретное утверждение, освежи, плиз.
Освежи.
v>>> Чтобы JIT сработал для в деле распространения констант, он должен видеть весь жизненный цикл данных, т.е. видеть, что некое приватное поле shift было проинициализировано некоей константой -10 и далее вплоть до того, что вместо for(int i=-10; i<=10; i++) в оптимизированном коде будет for(int i=0; i<21; i++) или даже вовсе раскрутит цикл. V>·>Аналогом обсуждаемого x: array[-10..10] of integer как раз и будет new ShiftedArray(-10, 10) т.е. приватные финальные поля, константы везде, в полный рост. V>Ты точно на джаве пишешь?
Не знаю, просто кнопки давлю, а там уж что получится. Но точно могу сказать, что ты на джаве не пишешь.
V>Какой в опу "в полный рост", если final поле меняется через рефлексию?
Не неси такой бред, тебя же люди читают.
V>Были же уже многократные обсуждения, почему само наличие рефлексии обрубает целый класс оптимизаций. V>Да и, без этих обсуждений, претендующий на звание "неновичка" должен хоть как-то себе представлять, как оно работает.
The specification allows aggressive optimization of final fields
Здравствуйте, novitk, Вы писали:
N>Начал играть недавно с Julia и имхо реально бомба. Версия >1.0 и народ проникся, в МIT вроде на ней уже студней учат.
Не видно никаких серьезных плюсов перед питоном (пока?), за исключением скорости.
Здравствуйте, novitk, Вы писали:
N>c) Индексация массивов с 1. Гребанный матлаб.
Меня гораздо больше напрягает column-major indexing. Если индексация с 1 еще удобна в определенных ситуациях, то это наследие матлаба нужно было смело закапывать.
Здравствуйте, Буравчик, Вы писали:
Б>Не видно никаких серьезных плюсов перед питоном (пока?), за исключением скорости.
Макросы, мултиметоды вместо ООП, нет GIL. Я как бы за Питон и считаю всякие там Ruby и R ненужными, но Julia/Clojure дают много нового.
Б>Но питон может быть быстрым, если надо.
Питон нет. numpy, cython — да, но это хаки все. numba вообще работает только для очень простого кода. Скорость очень сложно в язык добавить потом, о ней надо сразу думать. PyPy тому доказательство.
Б>см. статью о Julia и затем показательный комментарий к ней: https://habr.com/ru/post/427879/#comment_19290799
В показательном комментарии имхо написан бред. Вот тебе показательные примеры:
Язык Julia можно рассматривать как продолжение линии Fortran, где нам нужно написать числодробилку для каких-нибудь сеточных методов в таком императивном стиле, плюс распараллелить все по типу OpenMP.
Современный ответ на эту проблему это концепция потоковых полусимвольный графов вычислений. Что-то типа TensorFlow. Мы отделяем граф вычислений от потоков данных. Граф вычислений собираем из готовых блоков, которые автоматически распределяются под разнообразное железо.На мой взгляд Julia слишком низкоуровневая для этого. А вот Python подходит под эту концепцию на все 100%.
Здравствуйте, novitk, Вы писали:
N>Начал играть недавно с Julia и имхо реально бомба. Версия >1.0 и народ проникся, в МIT вроде на ней уже студней учат.
Очень нравился, пока не попробовал промышленно использовать. Из недостатков: медленный (реально, на числодробилки с кучей матриц — хорошо, остальное — тормозит); не хватает серьёзной конторы, чтобы навела порядок в процессе разработки языка; всё, что вне математических действий — куцое и кривое (по сравнению с питоном); синтаксис — видно, что разработан умными людьми в научных кругах. В общем, для прикидок на локальной машине меня и питон устраивает, а большие данные всё равно в облаке ворочать, там уже скорость исполнения одной операции — дело десятое.
Здравствуйте, novitk, Вы писали:
N>Здравствуйте, Буравчик, Вы писали:
N>Макросы, мултиметоды вместо ООП, нет GIL. Я как бы за Питон и считаю всякие там Ruby и R ненужными, но Julia/Clojure дают много нового.
Не думаю, что наличие макросов и мультиметодов сами по себе дадут существенное улучшение в производительности программиста. Скорее, они будут использоваться для создания удобных библиотек. Т.е. библитеки должны уметь то же, что и питон, причем стать еще более удобными из-за макросов и мультиметодов. И когда это будет?
Отсутствие GIL — да, плюс. Но сейчас проблемы с GIL в питон успешно обходятся.
N>Питон нет. numpy, cython — да, но это хаки все. numba вообще работает только для очень простого кода. Скорость очень сложно в язык добавить потом, о ней надо сразу думать. PyPy тому доказательство.
У питона и нет цели быть быстрым. У него задача — быть простым и гибким. Пусть библиотеку будут быстрыми.
Про numba не знаю, не использовал пока. Есть пример сложного кода, с которым numba не работает?
N>В показательном комментарии имхо написан бред. Вот тебе показательные примеры:
С чем ты не согласен? Идея в том, что вычисления надо описывать декларативно, а вычисляторы пусть сами разберутся как параллелить и что и как быстро вычислять (с использованием LLVM/C/CPU/GPU/cluster). Julia пытается стать удобной и быстрой числодробилкой (как фортран). Питон — остаться клеем (пусть медленным) между быстрыми числодробилками.
Питон у нас используется очень активно для мелких прикладных задач, для отработки алгоритмов можно использовать любой разумный инструмент, в основном это Matlab, но один ученый предпочитает julia. Почему бы и нет? Адаптировать основной фреймворк и CI для поддержки julia (Win/OSX/Linux) заняло примерно 2 недели, по деньгам это, наверное, сравнимо с лицензией на Matlab. Про количество библиотек ничего не скажу, т.к. сам ничего активно не делаю в этой области.
P.S. Наш data scientist очень доволен и вроде как продуктивен.
Здравствуйте, novitk, Вы писали:
N>Начал играть недавно с Julia и имхо реально бомба.
Бомба для чего? Мат обсчеты из numpy достаточно быстро считаются. Статистические пакеты- больше всего их в R.
LISP — мне видится ClojureScript более заманчивым, ибо его под nodejs и на фронтенде можно использовать, он оптимизируется под V8 из коробки.
Я ее пытался трогать несколько лет назад, но потом было ощущение, что на питон все побежали с датасаенсом. Что-то поменялось?
Здравствуйте, Буравчик, Вы писали:
Б>Не думаю, что наличие макросов и мультиметодов сами по себе дадут существенное улучшение в производительности программиста.
Не утверждаю, что производительность на J будет лучше чем на Py, скорее что она будет не хуже.
Что до мултиметодов, то я очень люблю единые и разделенные подходы, которые мы сейчас имеем например в Хаскеле, Ерланге и Clojure. Есть данные, есть функции — все. В Питоне и прочих гибридах все намешано из за того, что единственный удобный adhoc полиморфизм это single-dispatch. В результате в Питоне нужно все время думать как запихнуть модель в это прокрустово ложе и очень часто этот выбор достаточно субъективен и может быть не оптимален по мере эволюции кода или не работать вообще, то есть требовать multi-dispatch, который красиво просто не сделать.
Б>Скорее, они будут использоваться для создания удобных библиотек. Т.е. библитеки должны уметь то же, что и питон, причем стать еще более удобными из-за макросов и мультиметодов. И когда это будет?
Я не вижу причин почему это не будет. Clojure например уже имеет библиотеки в некоторых областях лучше питона.
Б>Про numba не знаю, не использовал пока. Есть пример сложного кода, с которым numba не работает?
numba оптимизирует нижние функции индивидуально, это такой локальный pypy. Если внутри типы выводятся и ничего внешнего о чем она не знает не вызывается — ок. Нет? досвидос.
N>>В показательном комментарии имхо написан бред. Вот тебе показательные примеры: Б>С чем ты не согласен?
С тем, что создание dataflow graphs очень удобно делать на Py, а на J почему-то нет. На самом деле Питон довольно средний язык для создания внутренних DSL. Лучше конечно чем Java, но по сравнению например со Скалой все очень плохо. Например макросы в этом деле сильно помогают. В качестве показательного примера сравни pandаs, в котором на каждый чих надо смотреть stackoverflow, и LINQ, который прост и понятен. Если что, linq завезли: https://github.com/JuliaData/DataFramesMeta.jl/blob/master/src/linqmacro.jl
Здравствуйте, Cyberax, Вы писали:
C>Проблемы: C>1. Компилятор таки достаточно небыстрый на больших объёмах, особенно при холодном старте.
Холодный старт до сих пор плохой, но народ говорит, что Revise.jl купирует проблему.
C>2. Плохой менеджмент потоков и памяти. Там свой планировщик задач на libuv, но работает он пока что посредственно.
C>3. У нас оно часто падало в Jupyter'е, требуя перезапуска ядра.
По слухам вроде сессии живут неделями.
C>Но само плохое — это отсутствие библиотек. Не хватает тонн вещей, особенно в области Machine Learning.
Да, это фигово. Однако PyCall мне очень понравился, то есть переползать можно плавно.
На днях хочу попробовать TF враппер: https://github.com/malmaud/TensorFlow.jl
Здравствуйте, $$, Вы писали:
>Бомба для чего?
One language to rule them all.
>Мат обсчеты из numpy достаточно быстро считаются. Статистические пакеты- больше всего их в R.
Быстро в Py считается только то, что другие люди закодировали на С. Именно поэтому до сих пор R и используют, портировать в Питон замучаешься.
>LISP — мне видится ClojureScript более заманчивым, ибо его под nodejs и на фронтенде можно использовать, он оптимизируется под V8 из коробки.
Clojure по скорости очень слабая, для числовой математики совсем негодная. ClojureScript это круто — да, но ScalaJS еще круче.
>Я ее пытался трогать несколько лет назад, но потом было ощущение, что на питон все побежали с датасаенсом. Что-то поменялось?
фиг знает, вроде она в рейтинге скакнула хорошо.
Здравствуйте, Cyberax, Вы писали:
C>Но это не фундаментальные проблемы, а просто болезни роста. Потому и вердикт — посмотреть чуть позднее.
А как давно это было?
Здравствуйте, novitk, Вы писали:
C>>Но это не фундаментальные проблемы, а просто болезни роста. Потому и вердикт — посмотреть чуть позднее. N>А как давно это было?
Февраль-март этого года.
Здравствуйте, novitk, Вы писали:
N>В показательном комментарии имхо написан бред. Вот тебе показательные примеры:
Однако, что не так? Intel, вон, начал делать oneAPI как раз для этого. Как раз видно, что низкоуровневые штуки типа OpenCL или HSA не взлетели, а необходимость в графах вычислений на разных устройствах есть.
Здравствуйте, Nuzhny, Вы писали:
N>Однако, что не так? Intel, вон, начал делать oneAPI как раз для этого. Как раз видно, что низкоуровневые штуки типа OpenCL или HSA не взлетели, а необходимость в графах вычислений на разных устройствах есть.
Здравствуйте, novitk, Вы писали:
N>Начал играть
Там уже можно сделать заранее откомпилированный бинарь программы без траходрома (не сильно сложнее, "cmake . && make")? Иначе "убийства" С++ и Fortran так и не состоялось.
Первое после старта процесса рисование прямой линии уже не занимает 40+ секунд?
N>c) Индексация массивов с 1. Гребанный матлаб.
Гребаный Fortran. Матлаб взял массивы (арифметика, слайсы) из Fortran, ну и индексацию тоже.
Здравствуйте, novitk, Вы писали: N>Холодный старт до сих пор плохой, но народ говорит, что Revise.jl купирует проблему.
Ну да. Амбиции-то — "убить" все устоявшиеся ЯП. A когда выявляются недостатки, которых нет в "убиваемых" ЯП, начинается строительство костылей, как этот Revise.jl Мне вспомнился анекдот про Эйнштейна и блондинку. Почему-то авторы Julia воображают, что Julia унаследует все хорошие черты "убиваемых" ЯП, а о наследовании плохих черт реклама умалчивает.
Здравствуйте, Cyberax, Вы писали:
C>Сейчас весь новомодный Machine Learning живёт, фактически, на 100% в Питоне. Где траходрома с установкой столько, что даже ./configure на снилось. В основном из-за того, что Питон используется как обёртка над библиотеками на чём попало. C>Julia тут как раз больше подходит из-за того, что на ней можно писать без использования С/C++, и оно будет достаточно быстро.
Вы, похоже, не поняли мою мысль. Вот именно, что Питон — _обертка_. Все эти фреймворки написаны на C++, а те из них, которые на Python все равно используют numpy, который тоже на C++. Таким образом, есть разделение труда и соответствующий выбор: если хочешь технических деталей, полного контроля над механизмами параллелизма, вылизанного за десятки лет промышленного применения оптимизирующего компилятора, пиковую производительность — берешь C++. Если не нужна вся эта инженерия, а нужно быстро провести численный эксперимент на конкретной и уже освоенной коммьюнити архитектуре — берешь Питон, и получаешь REPL, ноутбуки, и доступ к тем же фреймворкам на С++, и запросто может быть без существенных потерь в производительности, т.к. ботлнеки не на Питоне.
В случае с Julia этого выбора нет by design. Идея была — наплевать на принцип разделения труда и компромиссов при выборе того или иного инструмента (молотком неудобно шить, а иглой неудобно заколачивать гвозди), и решили создать супер-язык, one size fits all. Собрали со всех ЯП крутые фичи, запилили какую-то уродскую типизацию, и нахлобучили все это хозяйство на модный LLVM. В результате, на простых примерах, которые в два счета делаются на Питон (и не важно, вызывает ли он 90% времени код C++ — главное результат применения), на Джулии надо ждать, пока их мега-компилятор просрется, и нарисует самый простейший график. А для больших систем нафиг не сдалась эта необязательная типизация, и несмотря на компилируемость, все равно траходром с созданием standalone откомпилированной программы. И опять таки, если нет нужной библиотеки на Julia, надо ее либо переписывать, либо создавать раппер, т.е. шило на мыло по сравнению с Питоном.
Я понимаю, что некоторым людям надо как-то защищать диссеры, писать бумаги в журналы, тусить на конференциях и проч. Но это не значит, что все инженеры должны восхищаться их поделкой.
N>Начал играть недавно с Julia и имхо реально бомба. Версия >1.0 и народ проникся, в МIT вроде на ней уже студней учат. N>1) Пишется быстро. Питон не нужен.
библиотек нет многих, что есть на питоне, или на том же R N>2) Работает быстро, а если приложить руки, то очень быстро. C++ не нужен.
коммон, джулия убийца c++, это даже несмешно N>3) Компилирует быстро. Скала не нужен.
вот уж не ожидал здесь скалу увидеть. когда у скалы преимущество в скорости компиляции появилось? N>4) Доки — супер, репл — супер, jupyter kernel — супер.
репл как репл, jupyter как jupyter, питон пока явно стабильнее работает на ноутбуках (но это понятно не проблема языка)
нет GIL, макросы, и т.п. но не знаю, какого-то вау эффекта у меня все равно не было
N> Начал играть недавно с Julia и имхо реально бомба. Версия >1.0 и народ проникся, в МIT вроде на ней уже студней учат.
Мне по видеопрезентациям и докладам тоже понравился, но когда попробовал запрограммировать (несколько лет назад) один более-менее серьёзный алгоритм — начали вылезать всякие сырости (вставлю сюда из моих старых переписок):
1. Julia does not support full-value pointers, full-value recursive data types and full-value references (я ожидал, что будет получше для языка, который под алгоритмы из дискретки заточен).
2. IntSet (sorted set; implemented as a bit string) have the problem with big numbers: https://docs.julialang.org/en/stable/stdlib/collections/?highlight=intset#Base.IntSet (ссылка не доступна сейчас) — во тебе и крутая числодробилка.
3. The system function fill() have problems with references: https://github.com/JuliaLang/julia/issues/17796
Это всё прям на первой же задаче вылезло (а в других такие же мелочи). Задумок много хороших в Julia, но было сыро на реальных задачах. Прям чувствовал себя тестировщиком, когда кодил. Однако да, питон свой примитивностью языковой меня дико бесил (я вырос на Wolfram Mathematica) — хотелось чего-то покруче.
Общие ощущения субъективные были такими, что вот там макросы-шмакросы и прочий хорошо забытый хайтек, но будто программируешь на продвинутом Матлабе/Фортране — ощущаешь себя старпёром каким-то.
Здравствуйте, student__, Вы писали:
__>Вы, похоже, не поняли мою мысль. Вот именно, что Питон — _обертка_. Все эти фреймворки написаны на C++, а те из них, которые на Python все равно используют numpy, который тоже на C++. Таким образом, есть разделение труда и соответствующий выбор: если хочешь технических деталей, полного контроля над механизмами параллелизма, вылизанного за десятки лет промышленного применения оптимизирующего компилятора, пиковую производительность — берешь C++.
Вот только алгоритмы на Julia реально работают со скоростью быстрее С++, если использовать аналогичный функционал. В основном, за счёт векторизации, которая не очень работает в С++.
Фактически, обгоняет Julia только вылизанный код на ассемблере, заточенный под конкретные CPU.
Основная проблема с Julia в том, что можно случайно использовать конструкцию, которая будет работать медленно. Например, list comprehensions этим очень грешат. Местами ещё есть неприятные баги — недавно вот поправили то, что возведение в дробную степень не было оптимизировано никак.
D>Это всё прям на первой же задаче вылезло (а в других такие же мелочи). Задумок много хороших в Julia, но было сыро на реальных задачах. Прям чувствовал себя тестировщиком, когда кодил. Однако да, питон свой примитивностью языковой меня дико бесил (я вырос на Wolfram Mathematica) — хотелось чего-то покруче.
Не работал с математикой, но неужели язык выразительнее питона? Ведь и там и там, по сути, для решения соотв. задач вызваются API, т.е. соотв. мат. функции.
И что у Wolfram Mathematica может быть лучше питона в этом плане?
Здравствуйте, Cyberax, Вы писали: C>Вот только алгоритмы на Julia реально работают со скоростью быстрее С++, если использовать аналогичный функционал. В основном, за счёт векторизации, которая не очень работает в С++. C>Фактически, обгоняет Julia только вылизанный код на ассемблере, заточенный под конкретные CPU.
SIMD что ли? Не знаю, откуда такая информация. Это же надо сравнительный анализ на разных алгоритмах проводить (на gcc, intel и clang и как минимум на паре ходовых платформ). Когда мне нужен был SIMD на ARM в gcc, я просто взял интринзики. Код там один в один в ассемблер переводится, но назвать это ассемблерным кодом как-то язык не поворачивается.
В плане производительности на SIMD свет клином не сошелся. На маломальски больших объемах данных (даже уже для обработки изображений с современной вебкамеры), эффективнее использовать GPU. И в любом случае, оптимизируются боттлнеки. Просто надеяться на умный компилятор, что он разрулит все параллелизуемые места в программе как-то не серьезно. Всегда лучше явно контролировать, что именно и как оптимизируется в программе.
Здравствуйте, student__, Вы писали:
C>>Вот только алгоритмы на Julia реально работают со скоростью быстрее С++, если использовать аналогичный функционал. В основном, за счёт векторизации, которая не очень работает в С++. C>>Фактически, обгоняет Julia только вылизанный код на ассемблере, заточенный под конкретные CPU. __>SIMD что ли?
В основном, да. Хотя и не только он.
__>В плане производительности на SIMD свет клином не сошелся. На маломальски больших объемах данных (даже уже для обработки изображений с современной вебкамеры), эффективнее использовать GPU.
GPU не очень хорошо работают в алгоритмах, где нужно делать ветвление. У нас, например, это решение электросхем, где есть куча нелинейных элементов.
Здравствуйте, novitk, Вы писали:
N>5) Макросы и multiple dispatch, соответственно ООП выкинули. Clojure не нужен.
ООП выкинули — значит, что пишут только мелкие скриптики в repl или узкоспециализированые утилиты. Как только начнут писать тяжелые многофункциональные приложения, или ООП вернётся само собой, или язык останется в нише.
Здравствуйте, Ikemefula, Вы писали:
I>Например: агрегирование, делегирование, композиция, типы-подтипы, модули. Вот за это отвечает ООП.
Все эти концепции есть в Хаскеле, Джулии, Clojure, а OOPa нет.
I>Про сингл-диспатч смешно — 99% приложений писалось и по сей день пишется именно в таких языках.
90% приложений вообще на js лабают. Жизнь зла.
I>Мультидиспач может совмещаться и с ООП, принципиальных проблем нет. Проблемы в самом мультидиспаче — это пока достаточно непопулярная вещь. Например, мультиметод можно добавить в модуль. Так? Тут надо вспомнить, что класс в ООП это тип + модуль. Экземпляр в ООП это снова тип + модуль. Итого — всё в порядке в ООП мультидиспачем.
Какая-то схоластика. Есть языки которые умеют классический OOP и в них МД нет. Можно его туда завезти? Можно, так же как и сам OOP например в C(glib), но получится коряво.
Здравствуйте, novitk, Вы писали:
I>>Например: агрегирование, делегирование, композиция, типы-подтипы, модули. Вот за это отвечает ООП. N>Все эти концепции есть в Хаскеле, Джулии, Clojure, а OOPa нет.
Я тебе страшную вещь скажу — "класс" это единица проектирования, в коде он может быть выражен вообще никак — например, старый JS, до ES6 никаких классов не было в природе, а ООП было в полный рост. А вот объект это настолько широкое понятие, что сюда и замыкание подойдет, и вообще все что угодно.
Открываешь, скажем, веб-приложение, сервис какой на хаскеле, а еще лучше, скажем, десктоп UI приложение на каком нибудь wxWindows. Внезапно, половина книги GoF образуется сама собой.
Есть куча примеров как на хаскеле пишут игры, мобайл, десктоп, даже драйвера. Вот например в UI приложении все как один пилят модальную форму с кучей контролов как Form, что есть частный случай Mediator Для меню почему то реализауют композит на ко-монадах. Типа если ко-монада, то сразу и "не ООП"?
В веб приложении все хором пилят, например, Роутер, что снова есть частный случай всем известного паттерна GOF.
Типа, "сделано через pattern matching, а раз так, то роутер это роутер вовсе, ну и что, что обязанности те же, ну и что, что выглядит всё как в ООП
С начала времен важно не "как" а "что". Т.е. какие обязанности какой модуль-функция выполняют. А уже дело десятое, моделируешь ли ты класс, или замыкание, или создаешь объекты с полями-функциями, или заворачиваешь в монады или ко-монады.
Поведение, взаимодействие, абстрагирование, агрегирование, делегирование, композиция, подтипы, модули, состояние никуда не деваются. Разница исключительно в синтаксисе решения.
I>>Про сингл-диспатч смешно — 99% приложений писалось и по сей день пишется именно в таких языках. N>90% приложений вообще на js лабают. Жизнь зла.
Именно. А из оставшихся 10 пилят на шарпе, джаве, питоне, плюсах и обычным Си. Поэтому крайне странно заявлять про антипаттерны.
I>>Мультидиспач может совмещаться и с ООП, принципиальных проблем нет. Проблемы в самом мультидиспаче — это пока достаточно непопулярная вещь. Например, мультиметод можно добавить в модуль. Так? Тут надо вспомнить, что класс в ООП это тип + модуль. Экземпляр в ООП это снова тип + модуль. Итого — всё в порядке в ООП мультидиспачем. N>Какая-то схоластика. Есть языки которые умеют классический OOP и в них МД нет. Можно его туда завезти? Можно, так же как и сам OOP например в C(glib), но получится коряво.
Коряво, потому что эмулировать придется на библиотечном уровне. Но ничего не мешает встроить нужный синтаксис в язык и тогда бОльшая часть приседаний будет в компайл-тайм. ООП-шности ни прибавится, ни убавится. ООП может и так, и так.
Здравствуйте, Ikemefula, Вы писали:
I>ООП не имеет отношения к мутабельности и иммутабельности. Эта парадигма целиком вся не летает. Для неё нужен нижележащий слой — императивное (С++, C#, Java), функциональное (F#, Ocaml, Scala), реактивное, логическое программирование и тд. Т.е. ООП всегда живет на другой парадигме, т.к. отвечает не за вычисления, а за структуру решения. Например: агрегирование, делегирование, композиция, типы-подтипы, модули. Вот за это отвечает ООП.
Большую часть этого всего выбросили в Go. И ничего. Живёт так, что скоро Java начнёт теснить.
Здравствуйте, Cyberax, Вы писали:
I>>ООП не имеет отношения к мутабельности и иммутабельности. Эта парадигма целиком вся не летает. Для неё нужен нижележащий слой — императивное (С++, C#, Java), функциональное (F#, Ocaml, Scala), реактивное, логическое программирование и тд. Т.е. ООП всегда живет на другой парадигме, т.к. отвечает не за вычисления, а за структуру решения. Например: агрегирование, делегирование, композиция, типы-подтипы, модули. Вот за это отвечает ООП. C>Большую часть этого всего выбросили в Go. И ничего. Живёт так, что скоро Java начнёт теснить.
Имхо, от ООП реально нужно: объект с полями и методами; интерфейсы; возможность реализовывать несколько интерфейсов. Наследование объектов не нужно, только наследование интерфейсов.
Ну понятно, что желательно модификаторы видимости, но это уже, считаю, к ООП не относится, это более общая концепция модульности.
Здравствуйте, Cyberax, Вы писали:
I>>ООП не имеет отношения к мутабельности и иммутабельности. Эта парадигма целиком вся не летает. Для неё нужен нижележащий слой — императивное (С++, C#, Java), функциональное (F#, Ocaml, Scala), реактивное, логическое программирование и тд. Т.е. ООП всегда живет на другой парадигме, т.к. отвечает не за вычисления, а за структуру решения. Например: агрегирование, делегирование, композиция, типы-подтипы, модули. Вот за это отвечает ООП. C>Большую часть этого всего выбросили в Go. И ничего. Живёт так, что скоро Java начнёт теснить.
Не смеши людей. Агрегирование-делегирование-композиция-интерфейс это, например, обычный роутер веб приложения. Открой пример и посмотри сам.
Вероятно, для тебя ООП это три кита. На самом деле это необязательная модель. Вот например есть у тебя логирование — это уже ООП. Даже если ты его монадой writer реализуешь, всё равно это будет ООП.
Здравствуйте, ·, Вы писали:
·>Во-вторых, это можно юзабельным сделать только при хорошей системе типов. Ну, допустим, есть у тебя массив [-10..10]. И тебе надо иметь функцию поиска макс эл-та в списке. Зачем этой функции два индекса? Или где-то магически переиндексироваться должно? В рантайме, с накладными расходами? Или компилятор должен это как-то магически перекодировать?
Ну то есть инженеграм лень изучать системы типов. В Аде83 была индексация хоть по enum, и сейчас она есть, работает со скоростью Си.
Здравствуйте, Слава, Вы писали:
C>>Большую часть этого всего выбросили в Go. И ничего. Живёт так, что скоро Java начнёт теснить. С>Оно теснит скорее скрипты на bash и perl.
Kubernetes — 1.5 миллиона строк.
Здравствуйте, Cyberax, Вы писали:
I>>Вероятно, для тебя ООП это три кита. На самом деле это необязательная модель. Вот например есть у тебя логирование — это уже ООП. Даже если ты его монадой writer реализуешь, всё равно это будет ООП. C>ООП — это таки весь стиль программирования. Т.е. сокрытие реализации, доступ к внутренним данным объектов через методы, наследование реализации и т.п. Это всё, к счастью, начинает умирать. Даже в самых ударенных на ООП-голову языках как Java.
Это никакой не стиль, а парадигма. Только направлена не на вычисления, на структуру решения. В го сокрытие реализации есть, а традиционного наследования — нет. Это не страшно и непринципиально для ООП. Композиция гораздо важнее.
ООП в Джава сильно олдскульное. С тех пор много чего поменялось. Даже дотнет в этом плане староват. В Го — более современное. Как только ГО вытеснит дотнет с джавой по количеству нового кода, можно будет посмотреть, чего же в него натолкают к тому времени
C>Элементы ООП оказались полезны, да. Но практически это только интерфейсы и группировка функций в виде методов классов.
От агрегирования, делегирования, композиции отказаться не получится Смотри внимательно на роутер в примера по Го — он агрегирует хандлеры и делегирует им обработку каждого роута. Как только ты начнешь внедрять в библиотеку вещи, что бы облегчить сложные задачи, ООП само по себе попрёт изо всех щелей.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Здравствуйте, CreatorCray, Вы писали:
CC>>Здравствуйте, AlexRK, Вы писали:
ARK>>>Так это ж наоборот круто. CC>>Шоп да так ж нет!
MD>Кстати, вот удивляло: в Паскале самых ранних версий (т.е. даже не Delphi ещё) можно было делать индексы хоть отрицательными, хоть как. Просто пишешь "x: array[-10..10] of integer" и готово, получаешь массив на 21 элемент. Таким образом, индексацию можно было получить согласно задаче, а не исходя из memory layout, как это традиционно делается.
MD>Вопрос: почему другие языки не дают пользовательскую базу для индекса массивов? Инерция мышления?
В .NET есть поддержка, но в C# с таким работать чуть сложнее чем с обычными массивами.
using System;
using System.Linq;
namespace ConsoleApp8
{
class Program
{
static void Main(string[] args)
{
// -10 .. 9
Array data = Array.CreateInstance(typeof(int),
new int[] { 20 },
new int[] { -10 });
Console.WriteLine(data.GetLowerBound(0));
Console.WriteLine(data.GetUpperBound(0));
for (int i = -10; i < 10; i++)
{
data.SetValue(i, i);
}
Console.WriteLine(string.Join(", ",
Enumerable.Range(data.GetLowerBound(0), data.GetUpperBound(0)).Select(i => data.GetValue(i))));
}
}
}
Здравствуйте, ·, Вы писали:
·>В-третьих, зачем это встраивать в язык? Написать класс, который инкапсулирует обычный массив и shift — плёвое дело на любом современном языке.
Оптимизация страдает. Этот shift будет вызываться каждый божий раз.
Здравствуйте, vdimas, Вы писали:
V>·>В-третьих, зачем это встраивать в язык? Написать класс, который инкапсулирует обычный массив и shift — плёвое дело на любом современном языке. V>Оптимизация страдает. Этот shift будет вызываться каждый божий раз.
Во-первых, даже если такое встроено в язык тоже никакой оптимизации не гарантирует. Во-вторых, что такая проблема была только в ранних версиях Паскаля. Наверняка такие вещи вычищаются любым современным оптимизирующим компилятором на раз.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, D. Mon, Вы писали:
С>>>Оно теснит скорее скрипты на bash и perl. C>>Kubernetes — 1.5 миллиона строк. DM>Строк на Го. Т.е. на нормальных языках полторы тыщи будет.
Удар ниже пояса, однако.
Здравствуйте, ·, Вы писали:
V>>·>В-третьих, зачем это встраивать в язык? Написать класс, который инкапсулирует обычный массив и shift — плёвое дело на любом современном языке. V>>Оптимизация страдает. Этот shift будет вызываться каждый божий раз. ·>Во-первых, даже если такое встроено в язык тоже никакой оптимизации не гарантирует.
Это слишком общие рассуждения.
Некий трюк оптимизации либо доступен (напр., через распространение констант), либо нет.
В твоём варианте сразу нет.
·>Наверняка такие вещи вычищаются любым современным оптимизирующим компилятором на раз.
Забыл повторить про "плёвое дело на любом современном языке.". ))
Это возможно лишь в тех языках, где числовые константы могут быть частью параметризации типа.
Здравствуйте, vdimas, Вы писали:
V>>>Оптимизация страдает. Этот shift будет вызываться каждый божий раз. V>·>Во-первых, даже если такое встроено в язык тоже никакой оптимизации не гарантирует. V>Это слишком общие рассуждения. V>Некий трюк оптимизации либо доступен (напр., через распространение констант), либо нет. V>В твоём варианте сразу нет.
Откуда такая категоричность? Отсутствие фичи языка не означает, что код реализующий эту фичу не будет оптимизирован. А ты зуб даёшь что в ранних версиях паскаля эта оптимизация была? Повторюсь, наличие фичи не означает никакой оптимизации. Это ортогональные понятия. Зачем ты всё мешаешь в кучу — непонятно.
V>·>Наверняка такие вещи вычищаются любым современным оптимизирующим компилятором на раз. V>Забыл повторить про "плёвое дело на любом современном языке.". )) V>Это возможно лишь в тех языках, где числовые константы могут быть частью параметризации типа.
Верно. Там где парятся о перформансе, там такой трюк проворачивается. В C++ будут шаблоны с числами, в java почти наверняка сработает JIT. А скорее всего, даже лишний +- константы не будет оказывать никакого измеримого влияния на реальный код. Да ещё на самом деле ещё бы найти такой реальный код, в котором возникнет надобность такой фичи. В общем, мы как-то плавно свернули с обсуждения фич языка к перформансу...
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
V>>Некий трюк оптимизации либо доступен (напр., через распространение констант), либо нет. V>>В твоём варианте сразу нет. ·>Откуда такая категоричность? Отсутствие фичи языка не означает, что код реализующий эту фичу не будет оптимизирован.
Было дано необходимое условие — распространение констант.
Если ты не согласен с этим условием, аргументируй, плиз.
·>А ты зуб даёшь что в ранних версиях паскаля эта оптимизация была?
1. Попытка подмены тезиса, т.е. признание слабости своей позиции. ))
2. К тому же, ты не указал, о какой реализации речь, их же было около десятка независимых.
·>Повторюсь, наличие фичи не означает никакой оптимизации.
Повторение подмены тезиса.
·>Это ортогональные понятия. Зачем ты всё мешаешь в кучу — непонятно.
Если не видишь, что пытаешься одно утверждение заменить другим, то вовсе пичаль.
V>>·>Наверняка такие вещи вычищаются любым современным оптимизирующим компилятором на раз. V>>Забыл повторить про "плёвое дело на любом современном языке.". )) V>>Это возможно лишь в тех языках, где числовые константы могут быть частью параметризации типа. ·>Верно. Там где парятся о перформансе, там такой трюк проворачивается. В C++ будут шаблоны с числами, в java почти наверняка сработает JIT.
Чтобы JIT сработал для в деле распространения констант, он должен видеть весь жизненный цикл данных, т.е. видеть, что некое приватное поле shift было проинициализировано некоей константой -10 и далее вплоть до того, что вместо for(int i=-10; i<=10; i++) в оптимизированном коде будет for(int i=0; i<21; i++) или даже вовсе раскрутит цикл.
Т.е., может себе и сработает для временного объекта на стеке, но коллекции чаще используют в других сценариях — в кач-ве полей долгоживущих объектов.
Здравствуйте, vdimas, Вы писали:
v> V>>В твоём варианте сразу нет. v> ·>Откуда такая категоричность? Отсутствие фичи языка не означает, что код реализующий эту фичу не будет оптимизирован. v> Было дано необходимое условие — распространение констант. v> Если ты не согласен с этим условием, аргументируй, плиз.
Условие дано было тобой, притом в качестве примера. Зачем это условие было дано и какое это имеет отношение к начальному вопросу — мне непонятно.
v> ·>А ты зуб даёшь что в ранних версиях паскаля эта оптимизация была? v> 1. Попытка подмены тезиса, т.е. признание слабости своей позиции. )) v> 2. К тому же, ты не указал, о какой реализации речь, их же было около десятка независимых.
Нет, это попытка вернуть тебя обсуждаемому вопросу: "в Паскале самых ранних версий можно было делать индексы хоть отрицательными ... Вопрос: почему другие языки не дают пользовательскую базу для индекса массивов? Инерция мышления?"
v> ·>Это ортогональные понятия. Зачем ты всё мешаешь в кучу — непонятно. v> Если не видишь, что пытаешься одно утверждение заменить другим, то вовсе пичаль.
Ты сам с собой споришь опять. Я тебе не мешаю?
v> ·>Верно. Там где парятся о перформансе, там такой трюк проворачивается. В C++ будут шаблоны с числами, в java почти наверняка сработает JIT.
v> Чтобы JIT сработал для в деле распространения констант, он должен видеть весь жизненный цикл данных, т.е. видеть, что некое приватное поле shift было проинициализировано некоей константой -10 и далее вплоть до того, что вместо for(int i=-10; i<=10; i++) в оптимизированном коде будет for(int i=0; i<21; i++) или даже вовсе раскрутит цикл.
Аналогом обсуждаемого x: array[-10..10] of integer как раз и будет new ShiftedArray(-10, 10) т.е. приватные финальные поля, константы везде, в полный рост. А тебя опять куда-то понесло.
v> Т.е., может себе и сработает для временного объекта на стеке, но коллекции чаще используют в других сценариях — в кач-ве полей долгоживущих объектов.
Да это вообще бессмысленный спор. Пока никто так и не привёл даже примера использования такой конструкции, который можно было бы пообсуждать. А рассуждать о перформансе произвольного кода вещь неблагодарная.
Здравствуйте, ·, Вы писали:
v>> V>>В твоём варианте сразу нет. v>> ·>Откуда такая категоричность? Отсутствие фичи языка не означает, что код реализующий эту фичу не будет оптимизирован. v>> Было дано необходимое условие — распространение констант. v>> Если ты не согласен с этим условием, аргументируй, плиз. ·>Условие дано было тобой
Мной лишь озвучено вслух, а дано самой спецификой задачи.
·>притом в качестве примера.
Набор слов. ))
Мы всё еще говорим об оптимизации арифметических операций?
·>Зачем это условие было дано и какое это имеет отношение к начальному вопросу — мне непонятно.
О! Уже начальный вопрос!
Так сразу и скажи — имею желание слить, не знаю как. ))
Я отвечал на кое-какое твоё конкретное утверждение, освежи, плиз.
v>> Чтобы JIT сработал для в деле распространения констант, он должен видеть весь жизненный цикл данных, т.е. видеть, что некое приватное поле shift было проинициализировано некоей константой -10 и далее вплоть до того, что вместо for(int i=-10; i<=10; i++) в оптимизированном коде будет for(int i=0; i<21; i++) или даже вовсе раскрутит цикл. ·>Аналогом обсуждаемого x: array[-10..10] of integer как раз и будет new ShiftedArray(-10, 10) т.е. приватные финальные поля, константы везде, в полный рост.
Ты точно на джаве пишешь?
Какой в опу "в полный рост", если final поле меняется через рефлексию?
Были же уже многократные обсуждения, почему само наличие рефлексии обрубает целый класс оптимизаций.
Да и, без этих обсуждений, претендующий на звание "неновичка" должен хоть как-то себе представлять, как оно работает.
·>А тебя опять куда-то понесло.
Ага, в ликбез.
v>> Т.е., может себе и сработает для временного объекта на стеке, но коллекции чаще используют в других сценариях — в кач-ве полей долгоживущих объектов. ·>Да это вообще бессмысленный спор. Пока никто так и не привёл даже примера использования такой конструкции, который можно было бы пообсуждать. А рассуждать о перформансе произвольного кода вещь неблагодарная.
Здравствуйте, ·, Вы писали:
V>>Какой в опу "в полный рост", если final поле меняется через рефлексию? ·>Не неси такой бред, тебя же люди читают.
Т.е., не в курсе.
Так и запишем.
V>>Были же уже многократные обсуждения, почему само наличие рефлексии обрубает целый класс оптимизаций. V>>Да и, без этих обсуждений, претендующий на звание "неновичка" должен хоть как-то себе представлять, как оно работает. ·>
The specification allows aggressive optimization of final fields
В предполагаемой тобой реализации final-поле инициализируется переменной через конструктор, т.е. значение этого поля будет разное у разных экземпляров класса.
Сравни с примером по ссылке.
Ты, действительно не понимаешь, в чём разница?
Ага. ))
По ссылке пример, где объект создаётся в пределах метода и не покидает его границы, т.е. с большой вероятностью попал под escape analysis и был заинлайнен.
Хреново ты кнопки давишь, в общем...
Или всё понимаешь, но сознательно врёшь окружающим, как уже было, когда GC обсуждали.
Выдаёшь желаемое за действительное.
