Здравствуйте, novitk, Вы писали: N>Холодный старт до сих пор плохой, но народ говорит, что Revise.jl купирует проблему.
Ну да. Амбиции-то — "убить" все устоявшиеся ЯП. A когда выявляются недостатки, которых нет в "убиваемых" ЯП, начинается строительство костылей, как этот Revise.jl Мне вспомнился анекдот про Эйнштейна и блондинку. Почему-то авторы Julia воображают, что Julia унаследует все хорошие черты "убиваемых" ЯП, а о наследовании плохих черт реклама умалчивает.
Здравствуйте, student__, Вы писали:
N>>Начал играть __>Там уже можно сделать заранее откомпилированный бинарь программы без траходрома (не сильно сложнее, "cmake . && make")? Иначе "убийства" С++ и Fortran так и не состоялось.
Сейчас весь новомодный Machine Learning живёт, фактически, на 100% в Питоне. Где траходрома с установкой столько, что даже ./configure на снилось. В основном из-за того, что Питон используется как обёртка над библиотеками на чём попало.
Julia тут как раз больше подходит из-за того, что на ней можно писать без использования С/C++, и оно будет достаточно быстро.
Здравствуйте, 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 может быть лучше питона в этом плане?
Здравствуйте, BrainSlug, Вы писали:
N>>1) Пишется быстро. Питон не нужен. BS>библиотек нет многих, что есть на питоне, или на том же R
Да, но с Питоном интероп очень хороший, это вполне себе вариант для "неосновных" библиотек. Для основных типа tf, pandas, numpy варианты вроде есть. Понятно, что они отстают, но если язык станет популярен, это все чинится.
BS>коммон, джулия убийца c++, это даже несмешно
Для системных целей конечно нет, но в матмоделировании вполне.
BS>вот уж не ожидал здесь скалу увидеть. когда у скалы преимущество в скорости компиляции появилось?
Имеется ввиду, что скалу не дождешься.
Здравствуйте, 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>ООП выкинули — значит, что пишут только мелкие скриптики в repl или узкоспециализированые утилиты. Как только начнут писать тяжелые многофункциональные приложения, или ООП вернётся само собой, или язык останется в нише.
На lisp/clojure нет многофункциональные приложения?
Ты еще не в курсе, что классический ООП с мьютабильностью и single-dispatch это анти-паттерн?
Здравствуйте, novitk, Вы писали:
I>>ООП выкинули — значит, что пишут только мелкие скриптики в repl или узкоспециализированые утилиты. Как только начнут писать тяжелые многофункциональные приложения, или ООП вернётся само собой, или язык останется в нише.
N>На lisp/clojure нет многофункциональные приложения?
Браво — ты решил соскочить с Julia на lisp, clojure. И там, и там такие приложения за пределами статической погрешности. Можно пренебречь.
N>Ты еще не в курсе, что классический ООП с мьютабильностью и single-dispatch это анти-паттерн?
ООП не имеет отношения к мутабельности и иммутабельности. Эта парадигма целиком вся не летает. Для неё нужен нижележащий слой — императивное (С++, C#, Java), функциональное (F#, Ocaml, Scala), реактивное, логическое программирование и тд. Т.е. ООП всегда живет на другой парадигме, т.к. отвечает не за вычисления, а за структуру решения. Например: агрегирование, делегирование, композиция, типы-подтипы, модули. Вот за это отвечает ООП.
Хочешь использовать иммутабельность с ООП — пожалуйтса. Эту иммутабельность придумали несколько тысяч лет назад для ведения бухгалтерских книг. С чего бы в ООП было запрещено использовать такую древнюю вещь?
Про сингл-диспатч смешно — 99% приложений писалось и по сей день пишется именно в таких языках.
Мультидиспач может совмещаться и с ООП, принципиальных проблем нет. Проблемы в самом мультидиспаче — это пока достаточно непопулярная вещь. Например, мультиметод можно добавить в модуль. Так? Тут надо вспомнить, что класс в ООП это тип + модуль. Экземпляр в ООП это снова тип + модуль. Итого — всё в порядке в ООП мультидиспачем.
Здравствуйте, 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), но получится коряво.
Коряво, потому что эмулировать придется на библиотечном уровне. Но ничего не мешает встроить нужный синтаксис в язык и тогда бОльшая часть приседаний будет в компайл-тайм. ООП-шности ни прибавится, ни убавится. ООП может и так, и так.
Здравствуйте, Sharov, Вы писали:
I>>В веб приложении все хором пилят, например, Роутер, что снова есть частный случай всем известного паттерна GOF.
S>Можно подробнее, что за паттерн? Команда или стратегия ?
Chain of responsibility, он же роутер, он же конвейер(pipeline). Decorator, он же мидлвара, это транзитивный обработчик, например, подтягивает аутентификацию, парсинг, и тд., промежуточный процессинг. Команда — это обычно терминальный обработчик.
Все эти вещи будут независимо от парадигмы. Роль собтсвенно парадигмы — перевод конкретного решения в код. То есть, сначала решили задачу, а уже потом перевели в код. Паттерны являются готовым вариантом этого вот перевода. Потому очено смешно, когда товарищи функционалисты воюют с ооп, но при этом вовсю используют роутеры, мидлвары и тд
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, AlexRK, Вы писали:
ARK>>Так это ж наоборот круто. CC>Шоп да так ж нет!
Кстати, вот удивляло: в Паскале самых ранних версий (т.е. даже не Delphi ещё) можно было делать индексы хоть отрицательными, хоть как. Просто пишешь "x: array[-10..10] of integer" и готово, получаешь массив на 21 элемент. Таким образом, индексацию можно было получить согласно задаче, а не исходя из memory layout, как это традиционно делается.
Вопрос: почему другие языки не дают пользовательскую базу для индекса массивов? Инерция мышления?
Мне вспомнился анекдот про Эйнштейна и блондинку. Почему-то авторы Julia воображают, что Julia унаследует все хорошие черты "убиваемых" ЯП, а о наследовании плохих черт реклама умалчивает.
Для меню почему то реализауют композит на ко-монадах. Типа если ко-монада, то сразу и "не ООП"? 
