Как стать автором
Обновить

Комментарии 133

язык программирования с динамической типизацией

Хоть что-то не из прошлого века с такими исходными взлетело вообще? Это же похороны языка прямо с самого старта.

А что вас минусуют, хороший же вопрос ставите. Только его ещё чуть сократить надо: что вообще взлетело не из прошлого века?


Понятно, есть довольно много вещей, явно позиционирующихся как "Better Java(Script)". CoffeeScript, TypeScript, Kotlin. Scala сюда же: она как всё одновременно позиционируется, но в том числе — и, полагаю, наиболее важно для взлёта — таки как drop-in замена джаве. Groovy — самый интересный в контексте вашего вопроса случай: "улучшенная Java", причём "улучшенная" с помощью динамической типизации.


Взлетел ли Swift? Там своя атмосфера, термины свободного полёта я бы предпочёл к движениям в ней не применять.


А много ли взлетевших самостоятельных языков, чтобы пора было считать статистику их свойств?

Тайпскрипт вполне себе взлетел\взлетает с нормальной скоростью

Да, я его указал в списке успешных несамостоятельных языков. С другой стороны, по исходному вопросу любопытно, что он не только веселей всех взлетает, но и ближе всего к Julia в части системы типов, включая "динамичность", т.е. возможность объявить все переменные как implicit any.

НЛО прилетело и опубликовало эту надпись здесь
Rust

Ну да. И Go.

Скорее 'Ну нет. И Go.'

что вообще взлетело не из прошлого века?

.net.

Ага, переоценил возраст. Думал, оно чуть-чуть, но из прошлого века. На грани, но по 1.0 проходит. Третьим будет.

Там немного сложнее. Язык типизируется при JIT-компиляции. Типы можно объявлять, но на этапе компиляции это мало что дает из-за наличия мультиметодов.
Почему похороны? Типизация в Джулии очень продуманная. Вообще, если хотите — всегда можно задавать типы явно.
Хороший доклад на эту тему от одного из создателей:

Может быть Джулия не будет хватать звезд с неба, но язык по моему перспективный.
До джулии в основном на фортране немного писал, но ради интереса протестировал Джулию. Впечатления очень положительные — по крайней мере для простеньких задач скорость не уступала фортрану, а в некоторых случаях — превосходила. Может быть что компилятор фортрана у меня старый и он плохо оптимизирует.

Я в последний раз смотрел на Julia давным-давно, когда он только появился, так что, возможно, скажу глупость. Мне не очень понятна его целевая аудитория. Как язык общего назначения его вряд ли будут использовать, но так язык так себя и не позиционируют. Как замена матлаба? Ну, не знаю. Julia многословнее, сложнее отчасти, да и до матлабовского разнообразия инструметов далековато. Для тех же, кому матлаба мало, уже есть Python.


Если кто-то использует Julia на регулярной основе, напишите, пожалуйста, какие преимущества склонили вас к использованию этого языка (кроме любопытства :)).

Постоянно слышу о простой параллелизации из коробки (я сам язык не пробовал).
Только что попробовал. До параллелизации не дошел. С базой знаний — какой-то ад: еле нашел замену функции eye, которую благополучно убрали в одном из прошлых релизов. В linspace не хватает аргументов. Вообще, создалось впечатление, что собрались снобы и решили сделать идеальный язык методом выковыривания самых нужных функций потому что им они не нужны и вообще то же самое можно написать используя выражение с двойными скобками, оператором из стороннего модуля и какой-то там матери. einsum тоже не наблюдается (только сторонний модуль). Вся надежда на параллельное исполнение, но, боюсь, окажется, что там примерно те же проблемы что и в питоне. Но исполняется, конечно, очень быстро.
еле нашел замену функции eye, которую благополучно убрали в одном из прошлых релизов

Стрёмно очень! :(
Такой язык годится только для WRITE ONLY! кода. :(
Потому что при постоянной утере совместимости с предыдущими версиями поддерживание проекта станет постоянным мазохизмом. :(
Они только месяц как зарелизились. Странно было надеяться на то, что версия 1.0 будет полностью совместима с предыдущими как минимум потому, что это была одна большая бета.
кому матлаба мало, уже есть Python.

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

Ну, смотря какие задачи. Скажем, в статьях по deep learning матлаб и не встретишь уже. А вообще, да. Тулбоксы в матлабе на любой вкус.

в статьях по deep learning матлаб и не встретишь уж

Нуу прям:


https://scholar.google.ru/scholar?hl=es&as_sdt=0%2C5&as_ylo=2017&as_vis=1&q=deep+learning+%2Bmatlab&btnG=


А на сайте 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 встречается чаще. По крайне мере мне. :)

Мне синтаксис нравится существенно больше, чем у python или matlab. И стандартная библиотека логичнее устроена.
Мультиметоды очень приятны.
На регулярной основе не использую, изредка возникали задачи, в которых применял R, жду следующего случая, что бы попробовать Julia.
Думаю, ЦА — учёные, которым нужен полноценный язык. В Матлабе без боли только скрипты получаются, и то не всегда.
А в целом, зависит от области применения. Например, более убогий пакет для решения дифуров только в Пайтоне. А вот в Джулии уже запилили огромный набор интеграторов.
Мы пишем научный софт на Julia. Изначально использовали матлаб, но когда начали выходить на продакшн поняли, что нужно срочно искать альтернативу. Pyton очень медленный, чтобы на нем написать быстрый код нужно изрядно помучаться. Плюсы слишком сложные, да и по срокам бы никак не успели. Вот и пришлось остановиться на julia. Из основных плюсов для нас: большое количество библиотек сильно облегчающих написание научного софта, простой синтаксис чем-то похожий на матлаб, простое распараллеливание (как встроенное в Julia, так и mpi), простой дебаггинг и профилирование и т.д. Да и Julia, в отличие от того же матлаба, все-таки язык общего назначения и часть серверного бэкенда написана именно на ней.
Я к сожалению сейчас немного отошел от научных вычислений. Но чем меня в этом плане привлекла джулия. На матлабе или на питоне у тебя есть набор библиотек. Да, очень хороших и удобных. Но они же тебя и связывают по рукам и ногам. Попробуйте сделать на питоне какую-то вещь с массивами, которая не предусмотрена в numpy! Придется писать на самом питоне, что по сравнению с numpy будет дико тормозить. Либо писать модуль на С. На джулии же таких проблем нет. Библиотеки написаны на той же джулии. И если библиотеки перестало хватать, можно дописать свой код. Всё будет работать с той же скоростью. По-моему это огромное преимущество.
Ааа… Как можно пользоваться языком, у которого индексы массива начинаются с 1, а не с 0.

А если серьезно, 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. Я не спорю, что после получаса ковыряния гугла можно разобраться в большинстве библиотек, но если их используется десяток — то это уже пять часов. А самое главное — ради чего?

Приведите пример хотя бы одной библиотеки для Python, которая задокументированных также хорошо, как тулбоксы MATLAB.

Да хотя бы тот же Numpy. Чем плоха его документация?

range себя поведёт согласно своему докстрингу, который я получу с помощью команды help(range).

Аналогично выясняется поведение оператора :, и его уже не спутаешь с оператором/функцией из какой-то левой библиотеки с таким же названием.


По-сути чтобы понять, что делает функция, нужно как минимум 1. Идентифицировать функцию; 2. Идентифицировать библиотеку, к которой она относится. С операторами проще.

Вектор * скаляр = вектор. Если это подводный камень, то к научному софту лучше не прикасаться. Если же вы имели ввиду тип возвращаемого значения для единственной переменной, то питон в очевидности таких вещей ничем не лучше матлаба, потому что это вопрос а. Стандарта языка; б. Реализации функции.
Матлаб и матлабоподобные языки действительно удобнее и понятнее питона. Не говоря уже у numpy, которая действительно прекрасная библиотека (правда с необходимостью писать в тысячи раз больше букв и скобок, чем того требует задача), но так ею и останется, что ей никогда не простят те, кто писал на матлабе.
К тому же в питоне тоже немало способов выстрелить себе в ногу и непонятных и неочевидных вещей. Например отсутствие человеческих массивов и попытка скрыть это списками и numpy. Я сотни раз создавал n мерные массивы в фортране, матлабе и никогда это не вызывало у меня такой горечи, как попытка построить логику программы на срезах из двумерного списка, list(). Его даже опытные питонисты (не изучавшие других языков) ошибочно могут назвать array или matrix в двумерном варианте, хотя это очень далеко от истины.
И кстати, этот хитрый синтаксис с знаками препинания в ограниченном виде используется и в питоне, и это одна из самых приятных частей питона.
Матлаб тоже не без недостатков и в конечном счете его недостатки не позволили ему войти в IT. И не смотря на его активное развитие как продукта несколько лет назад (сейчас не слежу), он уже не займет нишу питона даже в области науки о

Покажите мне в моём примере умножение вектора на скаляр, сомнения по поводу того, что (с математической точки зрения) при этом получится, или возвращаемое значение для единственной переменной. Я говорил исключительно про сравнение range(x,y) и x:y с точки зрения читаемости.

В вашем примере синус — скалярная функция и с точки зрения формы возвращаемого результата нет разницы, умножаем ли мы скаляр на вектор или берем скалярную функцию от вектора — то же умножение можно обернуть в функцию и точно также применять к векторам.
С точки зрения читаемости, если понимать, как он работает без оглядки на питон как на эталон, он очень легко читается и, что тоже важно, очень быстро пишется. В конце концов он перекочевал и в питон в урезанном виде — для взятия срезов) Его наличие и необходимость в матлабе объясняется очень легко — почти все научные среды и яп используются для работы с матрицами и векторами, соответственно такой синтаксический сахар жизненно необходим.
Этот оператор, кстати, используется еще со времен фортрана и для меня было большим удивлением, что такие мощные абстракции были придуманы и использовались так давно)

Сечение массивов появилось только в Fortran 90 (как и многие другие полезные элементы языка), а Matlab был разработан в 80-х. Скорее всего это Fortran позаимствовал синтаксис у Matlab.

Я в основном в ф90 и работал, но судя по стандарту ф77 , срезы появились раньше. Но если вы правы, то все становится еще интереснее

Я тоже с Fortran 90 только, да и то давно. Я полистал стандарты, действительно какие-то зачатки срезов были аж в Fortran 66, но полноценные срезы массивов (не строк) появились именно в Fortran 90. Тогда же появилась возможность выполнять операции над срезами массивов, что сильно уменьшало число циклов.


Но вы оказались правы. Я погуглил немного и действительно, история намного интереснее, чем кажется на первый взгляд: Array slicing: History.

На самом деле там не упомянута одна очень забавная вещь: срезы Fortran 90 — это самая ужасная вещь, которая в нём есть.

Она прекрано ложилась на железо 90х (в Cray-2 есть специальная поддержка) и они казались разумными… но в современных архитектурах с быстрыми процессорами и медленной памятью — они вызывают чудовищную потерю производительноти. А с учётом того, что любая функция в F90 может их получить, но на практике 99.9% из не получают… получаем почти V8: приличные компиляторы генерируют все функции в двух экземплярах — со срезами и без (и диспечером на входе в «универсальную» функцию).

Прекрасный пример того, о чём говорится в широко обсуждаемой статье.
Итого Python хорош, когда у вас какой-нибудь некритичный проект типа поиска профилей в соцсетях по фоткам лиц людей и есть дешевая рабсила из Азии или Восточной Европы, тогда как для чего-то более серьёзного вроде авионики его никто в здравом уме использовать не станет.

Очень спорное утверждение, можете раскрыть мысль?
Для авионики действительно использовать его глупо. Там требуется высокая надежность и высокая производительность, Python не обеспечивает ни того, ни другого.
Но для авионики надежность Julia тоже не будет достаточной, динамическая типизация, сборки мусора и труднопредсказуемый JIT будут мешать.
Там требуется высокая надежность и высокая производительность, Python не обеспечивает ни того, ни другого.

Python сам по себе, в чистом виде мало кто использует, это язык-клей для высокопроизводительных библиотек, написанных на других языках. Этот язык прост и для него очень легко делать биндинги.


Дело не в надёжности и производительности самого языка. Если мы говорим об авионике как об электронном обрудовании самолётов, то там, уж извините, и Matlab никак не прикрутишь. Бортовая ЭВМ не потянет.


Если же мы говорим об авиастроительной отрасли и исследованиях, то там Python не прижился просто потому, что до него ниша уже была занята и не было нужды в чём-то ещё. Работает — не трогай.


К тому же Python популярен именно в открытых областях. В том же deep learning правило хорошего тона публиковать исходники, чтоб можно было воспроизвести твою работу. Естестенно выбрать среду, которая доступна большинству. И даже если Matlab и превосходит Python, цена это преимущество сводит на нет. В авиационной промышленности (я могу ошибаться, конечно) не принято вот так выкладывать исходники направо и налево.

>Matlab никак не прикрутишь. Бортовая ЭВМ не потянет

В automotive реально много где Simulink, транспиленный в C для для контроллера.

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

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

В MatLab все хорошо и красиво, когда решаешь стандартную задачу в рамках готового тулбокса. Но любой шаг в сторону превращается в большие мучения.

Для MatLab не сложилась индустрия развития платформы средствами сообщества. Это плохо. И нужно понимать, что сообщество это не только юные падаваны, но и вполне себе крутые профессора, которые пишут решения на пике технологий. И в последнее время это почти всегда python.

Вот к примеру расчет гравитационных волн от слияния черных дыр.

Полностью с вами согласен. В том сообщении я писал о Julia. Т.е. мне кажется, создатели хотели сделать копилируемый, опенсорсный Matlab, но слишком увлеклись. В итоге Matlab победил, так как ближе к практическим нуждам пользователей. В конце концов есть много людей, все рабочие потребности которых вполне покрываются одним-двумя тулбоксами. Их уже никуда не переманить, да и зачем?


А так я сам давно уже на Python перешёл по указанным вами причинам.

Ноль — это смещение первого элемента. Если не надо (а то и невозможно) работать напрямую с памятью, то индексы с единицы — это замечательно. На них хорошо ложатся естественные предметные области.
В том же Python поиск символа в строке возвращает его индекс. И что мы имеем? — отсутствие символа приводится к True, причём это индекс последнего элемента; если найден первый символ в строке результат приводится к False, если найден в других позициях — True. Это, конечно, быстро зазубривается, но нифига не логично и не красиво.

Явное лучше неявного. Просто не нужно приводить значение к bool неявно, если можно сравнить.

В общем, Джулия красива, умна и очень перспективна, и крайне непозволительно оставлять её без должного внимания.


Поумерю ваш пыл и добавлю ложку дёгтя:
1) Возможность использовать греческие символы и прочую ересь — это только красивая игрушка, бесполезная в прикладной разработке, поскольку она ломает одну из главных функций любого редактора кода/IDE — автодополнение кода, кроме того осложнит работу с кодом в непривычный среде — например в этой статье греческие символы неотображаются.
2) Управление пакетами даже хуже чем в python, особенно если сравнивать с maven и gradle.
3) Если сравнить скорость роста интереса сообщества к Джули с Растом и Котлином, то создается ощущение что это мертворожденый проект.
4) Качество существующих библиотек ужасное, научный код в его худших проявлениях, достойный наследник ROOT
5) Параллелизация из коробки на деле оказывается не такой уж фичей — в целом классе задача она бесполезна (например Монте-Карло методы, сбор данных) и нужна нормальная многопоточность/ асинхроность, а параллелизацию тензорных вычислений можно и в python получить. Koltin в этом плане удачнее.
6) Стремный синтаксис с точками восклицательными знаками, хорошо что в python нет этой matlabщины
НЛО прилетело и опубликовало эту надпись здесь
Ну Юникод — это просто стандарт сегодня. Даже в C++ он есть.
НЛО прилетело и опубликовало эту надпись здесь
Проблема в автодополнении. Когда вы используете допустим русский алфатит, то оно ещё работает, но когда вы как крутой математик начинаете писать на греческом, то возникают проблемы: греческой раскладки у вас нет, а если бы и была то это не решило бы проблемы, ведь есть ещё готический буквы, скандинвские руны и прочие символы.

В редакторах кода это решено следующим образом, вы начинаете набирать Lam, его можно автодополнить до Lambda и затем оно конвертируется в символ, но если в идентификаторе переменой есть такой конвертированный символ, то на этом идентификаторе перестает работать автодополнение, что делает эту фичу не просто бесполезной, но и вредной.

Какая из этих букв русская, а какая латинская: А и A? А ведь это разные имена переменных.

Ну Юникод я действительно не считаю прям таки каким-то преимуществом, но, например, выполнить курсовую в юпитере или сделать методичку на нем же вышло гораздо нагляднее с греческими символами, вот я и порадовался. На счет Питона особо не берусь сравнивать: за несколько дней прошел питон-тьютор, и он как-то наскучил своими придирками к пробелам ии табуляциям. Возможно Юлия цепляет некой романтикой — сразу чувствуется работа мечтателей. Но на красоту, простоту и мощь не стоит закрывать глаза. Поковырявшись пару вечеров в блогах и мануалах, я набросал на юпитере зачатки этого пособия, и всего вышеперечисленного материала вполне хватило, чтоб запилить решалку трехмерного волнового уравнения и прогу для моделирования фононных спектров. Не знаю на счет других универов, но у нас профессора понимаю только фортран, доценты учат сям и плюсам, а студенты перебиваются считалками типа маткада-матлаба, результаты которых предоставить нельзя так как у нас с нелицензиями строго. А питон задерживает внимание ненадолго — как правило у нас требовательные расчеты, хотя да, на NumPy Есть надежда. И тут у меня вопрос к хабровчанам — какой у нумпай порог вхождения для незнакомого с питоном человека? Скажем, для пользователя фартрана и с++?

После Fortran за день можно научиться писать какие-то вычислительные алгоритмы, где обычно ничего сложнее циклов нет, а если векторизовать вычисления, то и циклов не будет. Если есть опыт Matlab — так и вовсе за час пересесть можно, даже названия функций учить не придётся. :)


Хотя я когда-то занимался численными методами, и должен сказать, что Fortran 2008 очень даже неплох.

Основное использование Julia — через Jupyter. Там греческие буквы можно вводить как в TeX — написать \lambda и нажать табуляцию. При конвертации нотебука в pdf это выглядит красиво.
В функции myabs писать return не надо. Без него читабельнее.
Нет
Не очень понятны преимущества перед питоном — у того вроде тоже полно либ для этих целей.
Мультиметоды, простой синтаксис для замыканий, удобный REPL, высокая производительность.
В питоне работа с нумпишными массивами сильно отличается от родных списков, что создает неудобства.
А можно ссылки или подробности? Мультиметоды в питоне можно реализовать, конечно может не максимально красивым способом.
Замыкания куда уже проще?
Производительность специальных либ типа numpy разве хуже?
Julia мне нравится, но ложку дектя вылью.
Нумерация в массивах с единицы в 21 веке выглядит странно — вроде уже все привыкли, что ноль, это нормальное число.
Нет TCO. Хотя они не отказываются от ее полезности, но реализацию считают низкоприоритетной. Между тем рекурсивные программы часто нагляднее, что полезно при использовании языка в преподавании.

А что плохого в нумерации с единицы? Проще написать i=1:N чем i=1:N-1

Аксиоматика натуральных чисел логичнее, если в них включать ноль. То, что он выпадает из допустимых индексов несколько странно. Можно было бы пересмотреть семантику ':', что бы он не включал веркхниб границу, тожда было бы 0:N.
Даже если не обсуждать причины почему надо нумеровать с нуля (которые конечно же есть), понятно что это общепринято в отрасли и нужно иметь веские аргументы для того чтобы это менять.

В отрасли вообще-то общепринят фортран и матлаб.

Говоря отрасль я имел ввиду ту отрасль человеческой деятельности, которая опирается на Computer Science, а не группу пользователей конкретного математического пакета.
А что плохого в нумерации с единицы? Проще написать 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 даже потрудился пересказать они о стройности архитектуры, нельзя принимать решение опираясь на отдельный кейс, нужно принимать решения, которые имеют внутреннюю логику работающую хорошо или нормально во всех случаях.
masai даже потрудился пересказать они о стройности архитектуры,

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

А можете привести пример на каком-то реальном языке программирования где полезно на практике i=1:N?

В матлабе полезно: функции нахождения длины вектора возвращают количество элементов N, соответственно естественно писать 1:N для обозначения индексов всех элементов вектора.

Не вижу связи, также естественно писать 0:N

Индекс N при нумерации с 0 будет out of bounds.

Но если при этом использовать «полуинтервальную нотацию» (как в C++, когда последний индекс не входит в него), то всё будет нормально…
Не будет, вам стоило читать то, что вам тут писали.

Я уже писал, что подразумеваемое в данном случае невключение — неочевидно.

А это уже вопрос качества образования, всем образованным в ИТ должно быть очевидно, мне тоже было неочевидно пока добрые люди не прислали статью Дейкстры.

Это вопрос необходимости чтения доков к конкретной либе или языку, но если почитать современные стандарты написания надёжного ПО, то можно увидеть, что там продвигается идея явного указания всего, что можно. Лучше уж писать 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].

Так это не объединение матриц, а интервалов

list(range(0,5)) — это что?

Это список, но приведение к списку используется лишь для демонстрации, можно и сами интервалы складывать, если язык позволяет, вопрос в том, что интервал от x до y плюс интервал от y до z должен быть равен интервалу от x до z
НЛО прилетело и опубликовало эту надпись здесь
Да, правда второй интервал уже будет начинаться с y+1, что лучше? можно спорить, но интервал с включением правого не соответствует остальным требованиям, например разница между концом и началом не даёт числа элементов (а в случае [0:N), N есть число элементов)
en.wikipedia.org/wiki/Edsger_W._Dijkstra
he worked as a programmer at the Mathematisch Centrum (Amsterdam) from 1952 to 1962

чувак писал свои рекомендации программистам ручкой на бумаге
А должен был писати рекомендации на Фортране?
Это не личности, просто факт: чувак писал свои рекомендации программистам ручкой на бумаге.
А на чём он ещё должен был их писать во времена, когда для запуска программы на компьютере нужно было набирать её на перфокартах и ждать неделю, чтобы её кто-то запустил?

Если я вам скажу, что я не написал ни одной строчки кода — будете ли вы серьёзно относится к моим советам по программированию?
Как раз если выяснится, что вы знакомы только с современной технологией если достаточно долго месить чан с перловой кашей, в синтаксическом мусоре можно рано или поздно узреть лик Ларри Уолла и на листе бумаги не можете изобразить ничего — я буду относиться к вашим советом с куда большим подозрением, чем к советам человека, программы которого переносили на перфокарты «специально обученные люди» и который просто вынужден был думать о том как созданный им компилятор будет работать…
Дейкстра даже не программист был

Он, например, один из разработчиков компилятора ALGOL 60 и операционной системы THE. Думаю, он заслужил, чтобы к его аргументам хотя бы прислушаться.

С нулём проблема в приведении типов: Null -> 0 -> False
Что Null, что False должны быть вне диапазона индексов, а не приводиться/выводиться в реальный элемент массива/списка.

Такие приведения — это проблема конкретного языка, а не схемы индексирования.


Скажем, в Python None (аналог null) к 0 не приводится. В C вообще всё сложно. Скажем значение NULL может быть не равно нулю, хотя 0 всегда будет приводиться к NULL при преобразовании к void*.


Лучше вообще не пользоваться неявными приведениями типов в сколько-нибудь неоднозначных случаях.

Пакеты постоянно изменяются. Простая задача может занимать много памяти. Fortran + MKL считает быстрее.
простой вопрос — что будет при переполнении числа?

Проверил.


julia> UInt8(255) + UInt8(1)
0x00

Но есть BigInt для длинной арифметики.

любое число в расчетах можно переполнить, но будешь ли ты об этом знать?
Как я понял, «скорость как у Си» можно получить, только если использовать мультиметоды, но вот тут начинаются пляски, когда Джулия вываливает три страницы трейса, потому что ты вызвал
f(0, 1) 
вместо
f(0.0, 1.0).

Ну и постоянные перепиливания API — это жуть. Спёрли бы просто все названия у Матлаба, который и хотят заменить, и было бы всё ок.
Надеюсь, ко 2-й версии устаканится всё, хотя и сейчас уже большие вещи пишут.
Главные features языка Julia — это богатая система типов и multiple dispatch.
Благодаря ним можно писать единообразный лаконичный код:
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 (не всегда дает большой прирост в скорости). Более развернуто могу в отдельной статье, но если кому-то интересно, потому что писать статьи долго :)
«Это вопрос на статью, если вдруг кому-то нереально интересно, то могу написать.» —
было бы неплохо. А то все как-то набросились и я теперь в сомнениях: с одной стороны питонские инструменты, уже популярные и проверенные, а с другой стороны Юлия, про которую много обещаний, но со стороны публики холодный прием — как бы не свернули лавочку, и переучиваться потом с мертвого языка…
Все зависит от Ваших целей. Если хотите писать крупный проект с большим количеством сложно векторизуемых циклов, то на пайтоне придется повозиться (Numpy+Numba) и то вероятно в скорости проиграете. Вообще, у Julia очень низкий порог вхождения, так что попробовать можно, а там уже и к Python'у не захотите возвращаться)
А то все как-то набросились

А вы нас не слушайте. У нас свои задачи, у вас свои. :)

Было бы отлично, особенно сравнение.
Почему вдруг черт дёрнул писать на Julia и чем недостаточно было Python+numpy? Это вопрос на статью, если вдруг кому-то нереально интересно, то могу написать.

Поддерживаю, очень интересно!

Я сам долго мучался с проблемой выбора инструмента и все-таки остановился на Python. Да cython (местами уродливый), да numba (далеко не гарантия) и да, местами С. Но для моей задачи удалось очень хорошо локализовать эти критические места и аккуратно их спрятать за простой интерфейс. Зато на высоком уровне получилась сказка — просто, понятно и быстро за счет оптимизированного низкого уровня. Так получилось, что 70%-80% процентов активной разработки в моем проекте как раз было на верхнем уровне. В результате Python зашел просто идеально.

Но не всегда так бывает, конечно, поэтому очень интересно послушать мнение с другой стороны.
Хм, неужели я единственный, кто ассоциировал произношение/происхождение названия Julia с Множеством Жюлиа́?
Как говорят авторы языка, слово Julia не несет никакого смысла, просто красивое имя.

А уж прочтённое на испанский манер совсем хорошо звучит.

Julia пока не для продакшена. Она для data science. Чуваки в MIT написали, большинство лабораторий и университетов Америки для научных целей используют Julia. Очень быстрая при распараллеливании и подсчете на HPC. Matlab, который довольно хорош с математической базой, по скорости рядом и не стоял. Но люди, особенно ученые, хотят быстро что-то написать и запустить это на терабайте данных. Кстати говоря, опять же в американском научном обществе делают очень большие ставки на этот язык. Но единственное что пока в процессе разработки, это packages для машинного обучения и нейронки. Для всего такого, питон, конечно, лидер.
Чуваки в MIT написали, большинство лабораторий и университетов Америки для научных целей используют Julia.

А где писали? Любопытно посмотреть.

function mysin(t;A=1,?=1,?=0) # поддержка Юникода - можно использовать греческие символы

A*sin(?*t + ?)

end

Хабар скушал греческие символы и заменил на вопросики? Или код правильный?

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

function mysin(t;A=1,ω=1,φ=0)

А параметры со значениями по умолчанию должны отделяться от обычных параметров точкой с запятой?

Не обязательно, но если хочется обращаться к этим параметрам не по-порядку, то нужна точка с запятой

Было бы здорово почитать статью спустя пять лет. Как язык поменялся, какое место в мире занял.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории