Julia 0.4

Прикольная штука, все функции обощенные, типы алгебраические, есть примитывы для параллельных / распределенных вычислений. Компилятор в натив, вроде, был в планах.

Что немного отталкивает - везде позиционируется как язык для научных вычислений, а не общего назначения.

Чем оно лучше Python?

[вброс]Индексы массивов от единицы.[/вброс]

Как я понял - пытаются сделать интерпретатор с матлаб-подобным синтаксисом без ассемблера и с производительностью выше чем у октавы (хотя в последней скорость можно поднять в разы просто переписав 20-30 функций на С). Чем пузон лучше матлаба или чем матлаб лучше пузона думай сам.

Как можно сравнивать язык программирования с интерактивным калькулятором?

Выглядит интересно. Надо будет попробовать.

интерпретатор с матлаб-подобным синтаксисом

Он не совсем matlab-подобный. Вообще одна из целей это как раз уйти от matlab, т.к. изначально это был эдакий интерпретируемый fortran, а сейчас просто мешанина из всего, что прикрутили сбоку.

с производительностью выше чем у октавы (хотя в последней скорость можно поднять в разы просто переписав 20-30 функций на С)

У octave нет и в обозримом будущем не будет компиляции на лету, также другие проблемы в интерпретаторе, на которых теряется время.

В последний раз, когда рассматривал, даже дебаггера приличного не было. Сыро-зелено. Там работы на десяток лет, чтобы с текущим уровнем R/Python просто сравняться.

Что немного отталкивает - везде позиционируется как язык для научных вычислений, а не общего назначения.

А ты на его вообще смотрел? Он даже для «научных» вычислений слишком убоговат, подходит только для несколькострочных примеров типа посчитать факториал. Единственный его плюс по сравнению с остальными убоговатыми аналогами (~ octave) это JIT в реализации.

А сам-то пробовал, сказочник?

Хватит уже насиловать эту Юлию. Авторы - какие-то малолетние хипстеры, которым в разработку ЯП лучше ещё лет 20 не соваться. И которые кроме матлаба и SICP ничего не видели. Вердикт: такое говнище, что даже взлетит.

Лучше бы про Nim кто-то топик создал. Быстрый, современный, простой, питоний синтаксис, вывод типов, макросы, мультиметоды, компилируется в нативный код - всем пофиг.

Смотрел, но с позиции общего назначения. Я все-таки не ученый, и даже не математик, оценть его возможности в этом направлении не могу.

Радует очень, что там можно сроить визуализацию динамическую. За такое проекту большой респект!))

Лучше бы про Nim кто-то топик создал

Так было уже несколько, ждем 1.0 же.

Лучше бы про Nim кто-то топик создал. Быстрый, современный, простой, питоний синтаксис, вывод типов, макросы, мультиметоды, компилируется в нативный код - всем пофиг.

А вот это убожество точно пора закопать.

Мамку свою закопай.

Я не верю орлам, которые даже на уровне тестов производительности своего детища, умудряются играть в синтетическое типо превосходство над «типа конкурентами».

Под конкурентами подразумеваются R И Python?

типо превосходство

Разработчики Octave уже ругались, что тесты написаны от балды. А ещё их можно ненавидеть за систему сборки и зависимости.

Был в восторге от юлечки, пока не попробовал на ней писать программы. Тут и вылезает неадекватность авторов и отсутвие у них опыта. Индексация массивов от единицы? Нуууу, оооокей. Но когда слайсы включают верхнюю границу - это уже явный признак школоты, не читавшей Дейкстру. Потому что в юлии длина l[start:end] не равна разнице между end и start, как во взрослых языках. А равна end - start - 1. Это сраная +/-1 в юлечкиных программах вылазит повсюду. Как и в матлабовских, например. Но зачем мне второй сраный матлаб? Такого говна достаточно одного на весь мир, чтобы он содрогнулся. Но юлечкины родители решили выйти на новый уровень. Все приличные языки приучают писать лаконичный, идиоматический код, и он в них работает. Только не в юлии. Сами авторы на голубом глазу пишут: не надо складывать матрицы так: X = A + B. Надо так: for col=1:n, row=1:n X[row, col] = A[row, col] + B[row, col]. Вдобавок надо помнить, что у юлечке уёбищный порядок индексов, как в фортране (и в матлабе). Такое впечатление, что авторы ходили по помойкам истории и собирали все неудачные решения, от которых в цивилизованном мире давно отказались. Почему в XXI веке компилятор не может оптимизировать векторизованный код? Самое весёлое, что есть костылик Devectorize.jl, который разворачивает векторизованные операции до тупых фортран-стайл вложенных циклов - и они работают быстрее! Почему нельзя встроить это во встроенный оптимизатор? Потому что СРАНЫЕ КРЕТИНЫ. Потому что они всерьёз не понимают, чем плох низкоуровневый код и операции с индексами, чем плоха индексация массивов от 1 и закрытые интервалы. Просто элементарных вещей не осознают, что в тарболе julia-x.x.x.tar.gz дожет быть каталог julia-x.x.x, а не просто julia, что не надо в тарбол julia-x.x.x.tar.gz класть llvm-x.x.x.src.tar.gz, gmp-x.x.x.tar.gz, fftw-x.x.x.tar.gz и ещё килотонну зависимостей. Из какого заповедника они к нам выползли? Строгая типизация - че? join([«a», «b»], None) спокойно нам выдаст «aNoneb» - это что за ПХП вообще? Понятные сообщения об ошибках, удобный бэктрейс? У нас его есть:

ERROR: c not defined
 in include at /usr/bin/../lib/julia/sys.so
 in process_options at /usr/bin/../lib/julia/sys.so
 in _start at /usr/bin/../lib/julia/sys.so (repeats 2 times)
while loading /tmp/generate_latex_symbols_table.jl, in expression starting on line 23

Штоэтааа? Они про бэктрейс только в книжках читали? Пускай попросят маму сегодня перед сном им питон показать - вдруг им что-то умное приснится. А лучше пускай заползут под кровать и поплачут за плинтусом, потому что быть таким безудержным мудаком - СТЫДНО. Вывод редакции - julia не предназдачена для написания программ. Это вообще не язык программирования, а интерактивный калькулятор с расширенными возможностями скриптования. Убедительная просьба в тредах о языках программирования эту поделку не поминать.

Такое впечатление, что авторы ходили по помойкам истории и собирали все неудачные решения, от которых в цивилизованном мире давно отказались.

Так и есть, даже блоки с end не забыли откопать.

Вы когда в жизни предметы считаете, тоже начинаете от нуля? :)

Но когда слайсы включают верхнюю границу - это уже явный признак школоты, не читавшей Дейкстру

В GAP (да, та самая, вычислительная алгебра) - от 1. И тоже range включает верхнюю границу. Про учёных, профессоров, писавших GAP, тоже скажете что они - школота? :)

Нормально всё там, дело привычки. Каждому своё, математикам - абстракции, вычислителям - эффективность, а матлаб посередине. Может вас просто занесло не на свои галеры?

(по теме - про юлию - не в курсе, совсем)

а не общего назначения.

как общего не взлетит.

мешанина из всего, что прикрутили сбоку.

ну и нафига козе боян?

чем плоха индексация массивов от 1

И чем же?

The command line (REPL) now supports tab-completion of emoji characters

...

Да, теперь матлабу точно капец

В GAP (да, та самая, вычислительная алгебра) - от 1. И тоже range включает верхнюю границу. Про учёных, профессоров, писавших GAP, тоже скажете что они - школота? :)

Давно известно, что математиков к программированию лучше не подпускать.

Это классика, блджад. Это знать надо.

https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html

Adhering to convention a) yields, when starting with subscript 1, the subscript range 1 ≤ i < N+1; starting with 0, however, gives the nicer range 0 ≤ i < N

Вкусовщина же. «nicer» - это не объективный критерий

Ты не понимаешь, почему для N-элементной последовательности N + 1 is nicer than N? Надеюсь, всё у тебя будет хорошо.

Блджад, сам от тебя начинаю тупеть. N is nicer than N + 1. Покидаю в ужасе эту обитель скорби.

У octave нет и в обозримом будущем не будет компиляции на лету,

выдыхай, jit там есть, только кривой и мало чего умеющий. Кури флаги при сборке

Как можно сравнивать язык программирования с интерактивным калькулятором?

Ок, расскажи мне что умеет например пузон того, что матлаб ну вот вообще не умеет.

Читабельность, консистентность, низкий порог вхождения и уйма библиотек.

Не понимаю, почему N-1 is nicer than N для индекса последнего элемента, например.

Я прекрасно понимаю, что 0 очень удобен для адресации памяти, но в высокоуровневом языке все не так однозначно

Читабельность, консистентность, низкий порог вхождения

Я имел ввиду недостатки матлаба по сравнению с питоном, а не достоинства.

уйма библиотек

Да ну правда?

Такое впечатление, что ты вообще с языками программирования не знаком, не только с питоном.

Недавно пришлось писать кусок кода на Фортране, потому что аналогичный кусок на Скилабе нельзя было оптимизировать из-за необходимости писать лобовые циклы. В очередной раз почувствовал, что нумерация с единицы весьма естественна.

Не понимаю, почему N-1 is nicer than N для индекса последнего элемента, например.

Для индекса последнего элемента естественно использовать нотацию [-1]. А вот [-0] использовать не получится.

знаком. матлабный код читабельнее пузона и на порядок читабельнее крестов при решении любого матана. Если чего-то нету - добавь жабы.

И да - матлаб имеет свою нишу. Например он не умеет работу с памятью напрямую (вернее это делается через ту же жабу через жопу), но на том же руби писать файл-менеджер будет только очень тонкий ценитель. Равно как и работать с памятью в пузоне или писать численную модель на чистом С.

что умеет например пузон того, что матлаб ну вот вообще не умеет

недостатки матлаба по сравнению с питоном

Не думал, что ты настолько одарённый.

Я привёл достоинства питона.

Да ну правда?

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

Как можно сравнивать язык программирования с интерактивным калькулятором?

И да - матлаб имеет свою нишу. Без жабы не умеет того, того и того.

Питон умеет без жабы. Ещё вопросы есть?

графический тулкит

нативно - Guide. Либо компили либу и втыкай в любой проект хоть на смеси крестов с Qt

веб-фреймворк

на кой хрен он там нужен? это не язык общего профиля. Надо - в жабу.

реализацию регэкспов

функция regexp тебя спасет

Питон умеет без жабы.

питон не умеет без либ. Тот же scipy весь на С. Попытка лезть во что-то сложнее калькулятора без него - мазохизм.

это не язык общего профиля.

Этот срач начался с такого заявления. Если оно тебе очевидно, на кой хрен спорить?

нативно - Guide.

Ты правда считаешь это полноценным тулкитом?

питон не умеет без либ.

Умеет, просто через FFI производительнее.

Этот срач начался с такого заявления.

и где? Что высокоуровневый специализированный язык калькулятором назвали в лучших традициях HelloWorld-кодеров - было. А вот про язык общего профиля - не видел.

Ты правда считаешь это полноценным тулкитом?

нет. А что, у какого-то языка есть нативный тулкит, идущий без либ и прочего секса? Только про PyQt не надо, оно еще ужаснее чем TkInter, и это опять же доп либы. Гуй от кода не отделяли разве что в дельфи 15 лет назад (upd: ах да, шарп с дотнет, куда ж без них). У жабы нативный тулкит есть, если в ней есть хоть что-то что можно назвать нативным.

Умеет, просто через FFI производительнее.

Ну асм тогда тоже умеет, только без либ даже md5 считать задолбаешься. Получается не язык, а прям BPEL какой-то.

О, круто, помоги мне с матлабом. С самой его прекрасной частью — рисованием графиков. Надо на графике сделать такую подпись к оси: \bar x_{ТПЗ}. А потом экспортнуть график в какой угодно векторный формат, который сожрёт ворд. Хотя svg тоже подойдёт.

Тот же scipy весь на С

Просто ради протокола - не весь. ЕМНИП, меньше половины там на Си.

на том же руби писать файл-менеджер будет только очень тонкий ценитель. Равно как и работать с памятью в пузоне

Не знаю насчет пузона, но Python довольно прилично работает с сырой памятью. В Python 3 для этого даже специальных классов добавили.

На какие только страдание люди не идут, чтоб не юзать pgfplots.