Комментарии 133
язык программирования с динамической типизацией
Хоть что-то не из прошлого века с такими исходными взлетело вообще? Это же похороны языка прямо с самого старта.
А что вас минусуют, хороший же вопрос ставите. Только его ещё чуть сократить надо: что вообще взлетело не из прошлого века?
Понятно, есть довольно много вещей, явно позиционирующихся как "Better Java(Script)". CoffeeScript, TypeScript, Kotlin. Scala сюда же: она как всё одновременно позиционируется, но в том числе — и, полагаю, наиболее важно для взлёта — таки как drop-in замена джаве. Groovy — самый интересный в контексте вашего вопроса случай: "улучшенная Java", причём "улучшенная" с помощью динамической типизации.
Взлетел ли Swift? Там своя атмосфера, термины свободного полёта я бы предпочёл к движениям в ней не применять.
А много ли взлетевших самостоятельных языков, чтобы пора было считать статистику их свойств?
что вообще взлетело не из прошлого века?
.net.
Хороший доклад на эту тему от одного из создателей:
Может быть Джулия не будет хватать звезд с неба, но язык по моему перспективный.
До джулии в основном на фортране немного писал, но ради интереса протестировал Джулию. Впечатления очень положительные — по крайней мере для простеньких задач скорость не уступала фортрану, а в некоторых случаях — превосходила. Может быть что компилятор фортрана у меня старый и он плохо оптимизирует.
Я в последний раз смотрел на Julia давным-давно, когда он только появился, так что, возможно, скажу глупость. Мне не очень понятна его целевая аудитория. Как язык общего назначения его вряд ли будут использовать, но так язык так себя и не позиционируют. Как замена матлаба? Ну, не знаю. Julia многословнее, сложнее отчасти, да и до матлабовского разнообразия инструметов далековато. Для тех же, кому матлаба мало, уже есть Python.
Если кто-то использует Julia на регулярной основе, напишите, пожалуйста, какие преимущества склонили вас к использованию этого языка (кроме любопытства :)).
кому матлаба мало, уже есть Python.
Что-то я сильно сомневаюсь, что зоопарк свободных от гарантий библиотек Python когда-нибудь сравнится с матлабовскими тулбоксами.
Ну, смотря какие задачи. Скажем, в статьях по deep learning матлаб и не встретишь уже. А вообще, да. Тулбоксы в матлабе на любой вкус.
в статьях по deep learning матлаб и не встретишь уж
Нуу прям:
А на сайте MathWorks ещё и целая куча готовых рецептов использования — итого прототип чего угодно можно легко запилить за неделю даже без глубоких знаний всех тонкостей вместо хождения по граблям в течение месяца.
Не очень показательный список. Скажем, я открыл первую статью, и первое и единственное упоминание Matlab находится в списке литературы и выглядит так:
Collobert, R., Kavukcuoglu, K., Farabet, C., 2011. Torch7: A matlab-
like environment for machine learning. In: Advances in Neural
Information Processing Systems.
Не очень-то в пользу Matlab.
К тому же язык реализации обычно не упоминается в самой статье. Просто ссылка на Github где-то в сноске.
Хотя, конечно, с «не встречается», я погорячился. Если поискать, найти можно. Но вот по работе я каждый день просматриваю Arxiv Sanity и ни в одной статье, касающейся моей работы за последний год я матлаба не видел. Да, конечно, экстраполировать свой опыт на всех неправильно, но я не нашёл какой-то статистики по использованию фреймворков и инструментов.
Возьмите топовые статьи, которые продвинули deep learning, или доклады с топовых конференций. Там тоже матлаб — редкий гость. Не возьмусь утверждать, что его там совсем не будет, у той же NIPS 2018 один из спонсоров — MathWorks.
Но Matlab явно не самый популярный язык в этой области. Сами посудите. Deep learning сейчас продвигают крупные компании Facebook, Apple, Microsoft, Amazon и т. д., у них интерес практический. Да исследования с помощью Matlab проводить удобно, если ты привык к этому инструменту, хорошо его знаешь. Но приходит пора выкатывать твой код в продакшн. И тут начинаются проблемы. Не так-то просто запихнуть Matlab в Docker (к слову, даже на этапе исследований, не так-то просто и дёшево развернуть с десяток инстансов GPU на AWS с Matlab). Да, конечно, с недавних пор можно экспортировать модель в ONNX, но зачем удлинять цикл разработки и делать его дороже?
А вот в классическом Computer Vision, Matlab встречается чаще. По крайне мере мне. :)
Мультиметоды очень приятны.
На регулярной основе не использую, изредка возникали задачи, в которых применял R, жду следующего случая, что бы попробовать Julia.
А в целом, зависит от области применения. Например, более убогий пакет для решения дифуров только в Пайтоне. А вот в Джулии уже запилили огромный набор интеграторов.
А если серьезно, Julia это такой MatLab на стероидах. Писать большие программы на MatLab это ад, да и стоит MatLab просто бешеных денег. Поэтому в сообществе разработчиков научного софта возникла идея написать аналог MatLab'а, но с более качественным внутренним языком и open source.
Для того времени идея была верной. Научные расчеты на Python были в самом зачаточном виде, особых альтернатив не было. Авторы Julia признавались, что если бы к тому времени был бы NumPy, они бы не стали писать Julia.
И их идея частично удалась. В основе Julia одно из лучших ядер линейной алгебры и очень хорошие средства параллелизации. Если бы не выстрелил Python, сейчас Julia была бы ведущим языком для научных расчетов.
Но Python выстрелил. Благодаря NumPy. NumPy, конечно, просто гениальный проект. Python + NumPy это идеальный компромис между силой языка общего назначения и удивительной гибкостью, позволяющей строить очень ясные математические операции.
Сейчас уже в Python перетянули все самые полезные вещи, в том числе и из Julia: cupy — работа на GPU с интерфейсом NumPy, numba — JIT компиляция для научных расчетов, parallel accelerator стянутая из Julia автоматическая параллелизация, всем известный Tensorflow, и т.п.
В общем, если человек приходит из мира MatLab, Julia лучший выбор. Но в целом и общем, научный Python это лучше что есть в мире научного программирования.
Не сказал бы, что Python удобнее MATLAB: например там, где в MATLAB можно написать что-то вроде sin(1:5) в Python придётся писать зубодробительные list comprehensions типа [sin(x) for x in range(1,5)]. Аналога матлабовским тулбоксам в Python нет, а свободный от гарантий зоопарк библиотек не добавляет удобства использования.
Итого Python хорош, когда у вас какой-нибудь некритичный проект типа поиска профилей в соцсетях по фоткам лиц людей и есть дешевая рабсила из Азии или Восточной Европы, тогда как для чего-то более серьёзного вроде авионики его никто в здравом уме использовать не станет.
Python придётся писать зубодробительные list comprehensions
numpy часто облегчает такие вещи
np.sin(range(1,5))Не сказал бы, что Python удобнее MATLAB: например там, где в MATLAB можно написать что-то вроде sin(1:5) в Python придётся писать зубодробительные list comprehensions
Это не совсем верно, как раз NumPy и предоставляет удобную векторную нотацию, вот пример с sin
from numpy import sin, aranage
sin(arange(5))
А вот как раз пример матрично-векторных операций
import numpy as np
import numpy.linalg as la
n = 100
A = np.random.rand(n, n)
B = np.random.rand(n, n)
y = np.random.rand(n, 1)
# поэлементное умножение
C1 = A * B
# матричное произведение
C2 = A @ B
# решение СЛАУ с регуляризацией
E = np.eye(n)
x = la.inv(A.T @ A + E) @ A.T @ y
… тогда как для чего-то более серьёзного вроде авионики его никто в здравом уме использовать не станет.
Ну как сказать, если вбить в google 'aerospace python jobs' то количество вакансий от крупных компаний будет достаточно большим.
NumPy и предоставляет удобную векторную нотацию
С таким же успехом можно и на C++ это написать.
вбить в google 'aerospace python jobs
В aerospace тоже нужны фронтендеры и машин лернеры, я не такой aerospace имел ввиду.
Всё можно написать хоть на C++, хоть на брейнфаке. Тезис был про то, что благодаря нумпаю (и утиной типизации итерируемых объектов) можно в ряде случаев избежать громоздких comprehensions с четырьмя уровнями вложенности.
Ну и лично мне эстетически ближе цепочка функций, чем какой-то хитрый синтаксис на знаках препинания. np.sin(range(5)) — это две штуки, np.sin и range. Я могу понять, что в каком порядке вызывается, благо в питоне функции просто передают результаты друг в друга. Я могу для каждой посмотреть документацию, передать (в общем случае) сколь угодно большое число дополнительных параметров и вообще написать свой аналог, если вдруг захочется. Даже на незнакомом языке можно просто погуглить что-то типа "python3 range arguments" и разобраться. А синтаксический сахар вроде sin(1:5)может иметь тонну неочевидных подводных камней. Какого типа будут выходные числа? С каким шагом? Как себя поведёт sin(x:y) при x=2; y=4.5?
Какого типа будут выходные числа? С каким шагом? Как себя поведёт sin(x:y) при x=2; y=4.5
А range как себя поведёт? А какой-нибудь rng из библиотеки VelosipedPy? А где искать документацию к каждой библиотеке и всегда ли она есть? Прыжки по граблям.
Ну вот не надо сравнивать VeliosipedPy с официальными тулбоксами. Точно так же можно сравнивать самопальный тулбокс с тем же Numpy.
А где искать документацию к каждой библиотеке и всегда ли она есть?
К библиотекам, которые использует больше десятка человек документация как правило есть. Вы можете привести пример популярной научной библиотеки (а их обычно развивают крупные компании) у которой не было бы документации?
Прыжки по граблям.
Возможно, в вашей области, для Python действительно нет ни одной хорошей библиотеки. Что ж, бывает. Но не стоит абсолютизировать этот тезис. Хотя бы уточните, о какой области речь, или приведите пример из своего профессионального опыта.
не надо сравнивать VeliosipedPy с официальными тулбоксами
Проблема в том, что у Python официальных тулбоксов нет.
Но не стоит абсолютизировать этот тезис
Приведите пример хотя бы одной библиотеки для Python, которая задокументированных также хорошо, как тулбоксы MATLAB. Я не спорю, что после получаса ковыряния гугла можно разобраться в большинстве библиотек, но если их используется десяток — то это уже пять часов. А самое главное — ради чего?
range себя поведёт согласно своему докстрингу, который я получу с помощью команды help(range).
Аналогично выясняется поведение оператора :, и его уже не спутаешь с оператором/функцией из какой-то левой библиотеки с таким же названием.
По-сути чтобы понять, что делает функция, нужно как минимум 1. Идентифицировать функцию; 2. Идентифицировать библиотеку, к которой она относится. С операторами проще.
Вектор * скаляр = вектор. Если это подводный камень, то к научному софту лучше не прикасаться. Если же вы имели ввиду тип возвращаемого значения для единственной переменной, то питон в очевидности таких вещей ничем не лучше матлаба, потому что это вопрос а. Стандарта языка; б. Реализации функции.
Матлаб и матлабоподобные языки действительно удобнее и понятнее питона. Не говоря уже у numpy, которая действительно прекрасная библиотека (правда с необходимостью писать в тысячи раз больше букв и скобок, чем того требует задача), но так ею и останется, что ей никогда не простят те, кто писал на матлабе.
К тому же в питоне тоже немало способов выстрелить себе в ногу и непонятных и неочевидных вещей. Например отсутствие человеческих массивов и попытка скрыть это списками и numpy. Я сотни раз создавал n мерные массивы в фортране, матлабе и никогда это не вызывало у меня такой горечи, как попытка построить логику программы на срезах из двумерного списка, list(). Его даже опытные питонисты (не изучавшие других языков) ошибочно могут назвать array или matrix в двумерном варианте, хотя это очень далеко от истины.
И кстати, этот хитрый синтаксис с знаками препинания в ограниченном виде используется и в питоне, и это одна из самых приятных частей питона.
Матлаб тоже не без недостатков и в конечном счете его недостатки не позволили ему войти в IT. И не смотря на его активное развитие как продукта несколько лет назад (сейчас не слежу), он уже не займет нишу питона даже в области науки о
Покажите мне в моём примере умножение вектора на скаляр, сомнения по поводу того, что (с математической точки зрения) при этом получится, или возвращаемое значение для единственной переменной. Я говорил исключительно про сравнение range(x,y) и x:y с точки зрения читаемости.
С точки зрения читаемости, если понимать, как он работает без оглядки на питон как на эталон, он очень легко читается и, что тоже важно, очень быстро пишется. В конце концов он перекочевал и в питон в урезанном виде — для взятия срезов) Его наличие и необходимость в матлабе объясняется очень легко — почти все научные среды и яп используются для работы с матрицами и векторами, соответственно такой синтаксический сахар жизненно необходим.
Этот оператор, кстати, используется еще со времен фортрана и для меня было большим удивлением, что такие мощные абстракции были придуманы и использовались так давно)
Сечение массивов появилось только в Fortran 90 (как и многие другие полезные элементы языка), а Matlab был разработан в 80-х. Скорее всего это Fortran позаимствовал синтаксис у Matlab.
Я тоже с Fortran 90 только, да и то давно. Я полистал стандарты, действительно какие-то зачатки срезов были аж в Fortran 66, но полноценные срезы массивов (не строк) появились именно в Fortran 90. Тогда же появилась возможность выполнять операции над срезами массивов, что сильно уменьшало число циклов.
Но вы оказались правы. Я погуглил немного и действительно, история намного интереснее, чем кажется на первый взгляд: Array slicing: History.
Она прекрано ложилась на железо 90х (в Cray-2 есть специальная поддержка) и они казались разумными… но в современных архитектурах с быстрыми процессорами и медленной памятью — они вызывают чудовищную потерю производительноти. А с учётом того, что любая функция в F90 может их получить, но на практике 99.9% из не получают… получаем почти V8: приличные компиляторы генерируют все функции в двух экземплярах — со срезами и без (и диспечером на входе в «универсальную» функцию).
Прекрасный пример того, о чём говорится в широко обсуждаемой статье.
Итого Python хорош, когда у вас какой-нибудь некритичный проект типа поиска профилей в соцсетях по фоткам лиц людей и есть дешевая рабсила из Азии или Восточной Европы, тогда как для чего-то более серьёзного вроде авионики его никто в здравом уме использовать не станет.
Очень спорное утверждение, можете раскрыть мысль?
Но для авионики надежность Julia тоже не будет достаточной, динамическая типизация, сборки мусора и труднопредсказуемый JIT будут мешать.
Там требуется высокая надежность и высокая производительность, Python не обеспечивает ни того, ни другого.
Python сам по себе, в чистом виде мало кто использует, это язык-клей для высокопроизводительных библиотек, написанных на других языках. Этот язык прост и для него очень легко делать биндинги.
Дело не в надёжности и производительности самого языка. Если мы говорим об авионике как об электронном обрудовании самолётов, то там, уж извините, и Matlab никак не прикрутишь. Бортовая ЭВМ не потянет.
Если же мы говорим об авиастроительной отрасли и исследованиях, то там Python не прижился просто потому, что до него ниша уже была занята и не было нужды в чём-то ещё. Работает — не трогай.
К тому же Python популярен именно в открытых областях. В том же deep learning правило хорошего тона публиковать исходники, чтоб можно было воспроизвести твою работу. Естестенно выбрать среду, которая доступна большинству. И даже если Matlab и превосходит Python, цена это преимущество сводит на нет. В авиационной промышленности (я могу ошибаться, конечно) не принято вот так выкладывать исходники направо и налево.
Мне кажется, в какой-то момент желание реализовать крутые штуки победила прагматичность. Матлаб простой и мощный, этим он и хорош.
Для MatLab не сложилась индустрия развития платформы средствами сообщества. Это плохо. И нужно понимать, что сообщество это не только юные падаваны, но и вполне себе крутые профессора, которые пишут решения на пике технологий. И в последнее время это почти всегда python.
Вот к примеру расчет гравитационных волн от слияния черных дыр.
Полностью с вами согласен. В том сообщении я писал о Julia. Т.е. мне кажется, создатели хотели сделать копилируемый, опенсорсный Matlab, но слишком увлеклись. В итоге Matlab победил, так как ближе к практическим нуждам пользователей. В конце концов есть много людей, все рабочие потребности которых вполне покрываются одним-двумя тулбоксами. Их уже никуда не переманить, да и зачем?
А так я сам давно уже на Python перешёл по указанным вами причинам.
В том же Python поиск символа в строке возвращает его индекс. И что мы имеем? — отсутствие символа приводится к True, причём это индекс последнего элемента; если найден первый символ в строке результат приводится к False, если найден в других позициях — True. Это, конечно, быстро зазубривается, но нифига не логично и не красиво.
В общем, Джулия красива, умна и очень перспективна, и крайне непозволительно оставлять её без должного внимания.
Поумерю ваш пыл и добавлю ложку дёгтя:
1) Возможность использовать греческие символы и прочую ересь — это только красивая игрушка, бесполезная в прикладной разработке, поскольку она ломает одну из главных функций любого редактора кода/IDE — автодополнение кода, кроме того осложнит работу с кодом в непривычный среде — например в этой статье греческие символы неотображаются.
2) Управление пакетами даже хуже чем в python, особенно если сравнивать с maven и gradle.
3) Если сравнить скорость роста интереса сообщества к Джули с Растом и Котлином, то создается ощущение что это мертворожденый проект.
4) Качество существующих библиотек ужасное, научный код в его худших проявлениях, достойный наследник ROOT
5) Параллелизация из коробки на деле оказывается не такой уж фичей — в целом классе задача она бесполезна (например Монте-Карло методы, сбор данных) и нужна нормальная многопоточность/ асинхроность, а параллелизацию тензорных вычислений можно и в python получить. Koltin в этом плане удачнее.
6) Стремный синтаксис с точками восклицательными знаками, хорошо что в python нет этой matlabщины
В редакторах кода это решено следующим образом, вы начинаете набирать Lam, его можно автодополнить до Lambda и затем оно конвертируется в символ, но если в идентификаторе переменой есть такой конвертированный символ, то на этом идентификаторе перестает работать автодополнение, что делает эту фичу не просто бесполезной, но и вредной.
Какая из этих букв русская, а какая латинская: А и A? А ведь это разные имена переменных.
После Fortran за день можно научиться писать какие-то вычислительные алгоритмы, где обычно ничего сложнее циклов нет, а если векторизовать вычисления, то и циклов не будет. Если есть опыт Matlab — так и вовсе за час пересесть можно, даже названия функций учить не придётся. :)
Хотя я когда-то занимался численными методами, и должен сказать, что Fortran 2008 очень даже неплох.
К греческим буквам в коде я отношусь нервно с тех пор, как увидел в дикой природе функцию с локальными переменными p и ρ.
В питоне работа с нумпишными массивами сильно отличается от родных списков, что создает неудобства.
Замыкания куда уже проще?
Производительность специальных либ типа numpy разве хуже?
Нумерация в массивах с единицы в 21 веке выглядит странно — вроде уже все привыкли, что ноль, это нормальное число.
Нет TCO. Хотя они не отказываются от ее полезности, но реализацию считают низкоприоритетной. Между тем рекурсивные программы часто нагляднее, что полезно при использовании языка в преподавании.
А что плохого в нумерации с единицы? Проще написать i=1:N чем i=1:N-1
А что плохого в нумерации с единицы? Проще написать i=1:N чем i=1:N-1
Вы, наверное, имели в виду 0:N-1.
Вообще, об этом даже Дейкстра ещё писал в заметке «Why numbering should start at zero».
Если кратко, для диапазонов удобнее использовать полуотрезки a ≤ i < b, чем отрезки a ≤ i ≤ b, так как:
- полуотрезки легче объединять — точка разделения будет только в одном из них, и не придётся писать лишний раз
+1; - длину полуотрезка можно найти как
b - a.
А если у нас N элементов, то весь диапазон индексов задаётся как раз полуотрезком 0 ≤ i < N.
То есть, как раз при нумерации с нуля приходится реже прибавлять/вычитать единицу.
Второе преимущество (больше программистское, чем математическое) — семантика индекса как смещения относительно превого элемента.
Но, как и всегда, удобство нельзя оценивать в отрыве от задачи.
Забыл добавить, что 0:N-1 выглядит некрасиво именно в Matlab, который включает оба конца в диапазон. В том же Python, где используются полууотрезки, этот же диапазон выглядит как 0:N.
Дейкстра даже не программист был, так что практическая ценность его теоретических выкладок вызывает некоторые сомнения.
Объединение массивов в нормальном языке вроде MATLAB делается вообще без индексов. Нотация 1:N (не включая N) хуже тем, что невключение уже не очевидно.
Дейкстра даже не программист был
плавно переходим на личности, так скоро выясним что Дейкстра ещё и не с нашего района был.
Это не личности, просто факт: чувак писал свои рекомендации программистам ручкой на бумаге. Если я вам скажу, что я не написал ни одной строчки кода — будете ли вы серьёзно относится к моим советам по программированию?
masai даже потрудился пересказать они о стройности архитектуры,
Отлично, осталось привести пример на каком-то реальном языке программирования, чтобы понять, как это полезно на практике.
В матлабе полезно: функции нахождения длины вектора возвращают количество элементов N, соответственно естественно писать 1:N для обозначения индексов всех элементов вектора.
Индекс N при нумерации с 0 будет out of bounds.
Я уже писал, что подразумеваемое в данном случае невключение — неочевидно.
Это вопрос необходимости чтения доков к конкретной либе или языку, но если почитать современные стандарты написания надёжного ПО, то можно увидеть, что там продвигается идея явного указания всего, что можно. Лучше уж писать N-1, или переработать синтаксис.
В какой именно отрасли?
Computer science не ограничивается C-подобными языками. В области численных методов принят MATLAB и FORTAN, например.
list(range(0,5))+list(range(5,10)) == list(range(0,10))С +1 с первого взгляда понятнее, что куда входит, и что куда не входит. А вообще пример притянут за уши: например в MATLAB, когда нужно объединить матрицы A B C, пишется просто [A B C].
he worked as a programmer at the Mathematisch Centrum (Amsterdam) from 1952 to 1962
чувак писал свои рекомендации программистам ручкой на бумагеА должен был писати рекомендации на Фортране?
Это не личности, просто факт: чувак писал свои рекомендации программистам ручкой на бумаге.А на чём он ещё должен был их писать во времена, когда для запуска программы на компьютере нужно было набирать её на перфокартах и ждать неделю, чтобы её кто-то запустил?
Если я вам скажу, что я не написал ни одной строчки кода — будете ли вы серьёзно относится к моим советам по программированию?Как раз если выяснится, что вы знакомы только с современной технологией если достаточно долго месить чан с перловой кашей, в синтаксическом мусоре можно рано или поздно узреть лик Ларри Уолла и на листе бумаги не можете изобразить ничего — я буду относиться к вашим советом с куда большим подозрением, чем к советам человека, программы которого переносили на перфокарты «специально обученные люди» и который просто вынужден был думать о том как созданный им компилятор будет работать…
Дейкстра даже не программист был
Он, например, один из разработчиков компилятора ALGOL 60 и операционной системы THE. Думаю, он заслужил, чтобы к его аргументам хотя бы прислушаться.
Что Null, что False должны быть вне диапазона индексов, а не приводиться/выводиться в реальный элемент массива/списка.
Такие приведения — это проблема конкретного языка, а не схемы индексирования.
Скажем, в Python None (аналог null) к 0 не приводится. В C вообще всё сложно. Скажем значение NULL может быть не равно нулю, хотя 0 всегда будет приводиться к NULL при преобразовании к void*.
Лучше вообще не пользоваться неявными приведениями типов в сколько-нибудь неоднозначных случаях.
f(0, 1) f(0.0, 1.0).Ну и постоянные перепиливания API — это жуть. Спёрли бы просто все названия у Матлаба, который и хотят заменить, и было бы всё ок.
Надеюсь, ко 2-й версии устаканится всё, хотя и сейчас уже большие вещи пишут.
Благодаря ним можно писать единообразный лаконичный код:
rand() # случайное число на [0, 1]
rand(n) # случайный вектор с координатами, р.р. на [0,1]
rand(m, n) # случайная матрица размера m x n
rand(k, m, n) # случайный трехмерный массив и т.д.
using Distributions # подключаем пакет с распределениями, аналог import
d= Normal() # и используем, например, станд. норм. распр.
rand(d) # случайное число, взятое из распределения d
rand(d, n) # случайный вектор... и так далее
Одна функция = множество методов, каждый заточен на свой тип и компилируется в довольно шустрый llvm-код. Ещё пример:
using DataFrames
using RDatasets # пакет со всякими известными датасетами
df = dataset("datasets", "iris")
df[1, :] # первая строка датафрейма df
df[:, 1] # первый столбец датафрейма df
df[:Species] # столбец с именем Species
Аналогично pandas-ам можно индексироваться и по булевским векторам, и по range. Но без всяких loc-iloc.
Другой пример предоставляет пакет Plots с его универсальной функцией plot на все случаи жизни.
Второе, чем хороша — легкая обратная связь посредством REPL.
Макросы @benchmark (аналог %timeit в ipython) и @code_llvm — для просмотра сгенерированного низкоуровневого кода. Если видно, что в @code_llvm какая-то беда, то, манипулируя высокоуровневыми абстракциями и используя этот макрос, можно добиться хорошего качества низкоуровневого кода (при этом не написав ни одной строки на ассемблере).
Для получения справки по функции достаточно набрать ?<имя>, для выхода в bash и навигации по файловой системе к примеру — начать команду с; (и т.д., так что REPL в Julia очень умная, аналог ipython).
Почему вдруг черт дёрнул писать на Julia и чем недостаточно было Python+numpy?
Это вопрос на статью, если вдруг кому-то нереально интересно, то могу написать. Короткий ответ такой: python + numpy абсолютно ОК до тех пор, пока вы не выходите за пределы векторизованных операций (единообразные преобразования датафреймов, всякая лин.алгебра и т.д.). Если вы начинаете писать что-то своё с большим кол-вом циклов (см., например, NIST-овские тесты на псевдослучайность последовательности, к примеру алгоритм Берлекэмпа-Месси и т.д.) — начнутся проблемы со скоростью. Дальше будет либо cython (с линтером, с уродливыми типами, да и вообще, почему бы тогда сразу не писать на Си?), либо numba (не всегда дает большой прирост в скорости). Более развернуто могу в отдельной статье, но если кому-то интересно, потому что писать статьи долго :)
было бы неплохо. А то все как-то набросились и я теперь в сомнениях: с одной стороны питонские инструменты, уже популярные и проверенные, а с другой стороны Юлия, про которую много обещаний, но со стороны публики холодный прием — как бы не свернули лавочку, и переучиваться потом с мертвого языка…
А то все как-то набросились
А вы нас не слушайте. У нас свои задачи, у вас свои. :)
Почему вдруг черт дёрнул писать на Julia и чем недостаточно было Python+numpy? Это вопрос на статью, если вдруг кому-то нереально интересно, то могу написать.
Поддерживаю, очень интересно!
Я сам долго мучался с проблемой выбора инструмента и все-таки остановился на Python. Да cython (местами уродливый), да numba (далеко не гарантия) и да, местами С. Но для моей задачи удалось очень хорошо локализовать эти критические места и аккуратно их спрятать за простой интерфейс. Зато на высоком уровне получилась сказка — просто, понятно и быстро за счет оптимизированного низкого уровня. Так получилось, что 70%-80% процентов активной разработки в моем проекте как раз было на верхнем уровне. В результате Python зашел просто идеально.
Но не всегда так бывает, конечно, поэтому очень интересно послушать мнение с другой стороны.
function mysin(t;A=1,?=1,?=0) # поддержка Юникода - можно использовать греческие символы
A*sin(?*t + ?)
end
Хабар скушал греческие символы и заменил на вопросики? Или код правильный?
Скушал. Исправил - статья написана давно, тогда не было поддержки языка. С нынешним опытом я бы многое в статье изменил, но наверно было бы лучше переписать новую с более актуальными подводными камнями
Публикации
Julia. Знакомство