Спустя шесть лет с момента первого анонса сформирован (https://julialang.org/blog/2018/08/one-point-zero) первый стабильный релиз языка программирования Julia 1.0 (https://julialang.org), сочетающего такие качества как высокая производительность, поддержка динамической типизации и встроенные средства для параллельного программирования. Синтаксис Julia близок к MATLAB с заимствованием некоторых элементов из Ruby и Lisp. Метод манипуляции строками напоминает Perl. Код проекта распространяется (https://github.com/JuliaLang/julia) под лицензией MIT.Ключевые особенности языка:
- Высокая (https://julialang.org/benchmarks/) производительность: одной из ключевых целей проекта является достижение производительности близкой к программам на языке Си. Компилятор Julia основан на наработках проекта LLVM и генерирует эффективный нативный машинный код для многих целевых платформ;- Поддержка различных парадигм программирования, включая элементы объектно-ориентированного и функционального программирования. Стандартная библиотека предоставляет в том числе функции для асинхронного ввода/вывода, управления процессами, ведения логов, профилирования и управления пакетами;
- Динамическая типизация: язык не требует явное определение типов для переменных по аналогии со скриптовыми языками программирования. Поддерживается интерактивный режим работы;
- Опциональная возможность явного указания типов;
- Синтаксис, превосходно подходящий для численных вычислений, научных расчётов, систем машинного обучения и визуализации данных. Поддержка многих числовых типов данных и средства для распараллеливания вычислений.- Возможность прямого вызова функций из библиотек на языке Си без дополнительных прослоек.
Кроме стабилизации языка в Julia 1.0 также представлено несколько новшеств, среди которых новый встроенный пакетный менеджер Pkg (https://docs.julialang.org/en/latest/stdlib/Pkg/), позволяющий не только манипулировать репозиториями и устанавливать пакеты и связанные с ними зависимости, но и создавать привязанные к проектам окружения пакетов, записывать и воссоздавать состояние работающего приложения, использовать приватные пакеты. Для переменных добавлено новое значение "missing", определяющее отсутствующее значение. Встроенные тип String адаптирован для хранения произвольных данных.
Добавлена поддержка именованных кортежей (похожи на хэши в Perl). Добавлена возможность переопределения оператора "точка". Расширены возможности оптимизатора.URL: https://julialang.org/blog/2018/08/one-point-zero
Новость: https://www.opennet.ru/opennews/art.shtml?num=49109
Назвал null missing'ом — все проблемы моментально исчезли.
в функциональном мире это слово запрещено произносить вслух
Нет, это далеко не null и даже питоновский None или плюсовой std::optional. Тут повеселееjulia> missing + 1
missingjulia> "a" * missing
missingjulia> abs(missing)
missingjulia> missing == 1
missingjulia> missing == missing
missingjulia> missing < 1
missingjulia> 2 >= missing
missing
А самое главное, как будет реагировать на if !missing ? :)
Вот так:
-> if !missing
-> missing
В SQL (по крайней мере, постгрес) NULL себя точно так же ведёт
Типичный null. Непонятен смысл обзывания по другомц.
Это же обычный NaN
Нет.
>missing == missingmissing
>NaN == NaN
false
Здесь акцент на то, что данные бывают разряженными. То есть, если их нет, то нет. Сравнивать что-то с отсутствующими данными - это ошибка. Впрочем, описать логику преобразования к чему-то другому, в Julia можно.
Значит это просто пустой массив, как в матлабе [] и тест isempty?
https://julialang.org/blog/2018/06/missing
Нет "не число" это не число, а null - это ОТСУТСВИЕ ЧЕГО БЫ ТО НИБЫЛО
>ОТСУТСВИЕ ЧЕГО БЫ ТО НИБЫЛОДавай ты мне накачаешь воздушный шарик вакуумом.
Не получилось? А вот набить таблицу в 9000 строк в SQL базе NULL-ами получается.
Задумайся над этим.
Да без проблем. 9000 шариков, из которых откачан воздух. Какой газ содержится в этих шариках? NULL.
> Нет, это далеко не nullВ точности SQL-ный NULL, судя по приведённым примерам
Так это и есть null
Выглядит крипово. Как шелл после патча Бармина: что ни выполняй, результат один и тот же.
Наконец-то правильная реализация null
Динамическая типизация = язык "для накидать чего-нибудь по-быстрому на коленке". В больших проектах от этого сплошной геморрой. Питонам и жабоскриптам оно простительно - языки из 90-х. Но стоило же посмотреть хотя-бы на опыт Typescript и Dart 2.
typescript вроде годная штука, чего ты?
Она годная именно тем, что строго статически типизирована, как и вторая версия дарта.
Корявая она там. Даже в строгом режиме можно суметь выстрелить себе в ногу.
Примеры есть? К тому же, за последние пару лет Julia сильно поменялась. Даже в рамках 0.6 были существенные изменения.
>К тому же, за последние пару лет Julia сильно поменяласьЯзык программирования это не меню в столовой. Часто менять язык вредно.
Ей 6 лет от роду. И первый стабильный релиз с зафиксированным API.
>Ей 6 лет от роду. И первый стабильный релизЕще одна причина держаться от языка подальше.
> Еще одна причина держаться от языка подальше.В отношении Julia утверждение неверное. К ней слишком ответственно отнеслись за это время. По сути - она язык, не имеющий конкурентов в области математики и машинного обучения. Те конкуренты, которые есть - сильно платные. Предвидя возражения, питон ей не конкурент, поскольку на нём алгоритмы не пишут и без связки с C не используют.
Перевожу на понятный язык.
>К ней слишком ответственно отнеслись за это время.положили болт.
>По сути - она язык, не имеющий конкурентов в области математики и машинного обучения.Неуловимый Джо, не имеющий конкурентов в неуловимости.
>Те конкуренты, которые есть - сильно платные.Выдуманные мной "конкуренты" стоят сто тысяч мильонов!
>Предвидя возражения, питон ей не конкурент, поскольку на нём алгоритмы не пишут и без связки с C не используют.Пластилин лучше железа, из пластилина можно слепить и здание и самолет и пароход!
В ЖЖ можно поискать про R. И там найти многое про "не имеющего конкурентов". А так же как они бенчмарки пишут. И как они реагируют на письма от пользователей других языков с словами - я языке ХХХ так никто не делает, правильный вариант вот такой.
Что за бред ты несешь. ЯП это просто инструмент. Есть конечно любимые, но выбор в 90% случаев зависит от задачи и ее условий.
Представьте что дрели делали как языки программирования.
Сегодня ваша дрель сверлит круглые отверстия.
Завтра производитель решил что это уже не модно и ваша дрель стала сверлить квадратные
Послезавтра обновление на версию 3.0 и дрель превратилась в полосатое дилдо.
Пока языком пользуется полтора анонимуса, то это вполне нормальная практика (если используется для устранения косяков, а не просто набахать побольше рандомного сахара)
Я TS имел в виду.
Проблема с TypeScript и Dart в том, что всё-равно приходится взаимодействовать с JS-библиотеками. И в местах подобного взаимодействия код неумолимо превращается в гoвнo т.к. эти библиотеки навязывают принятый в JS стиль написания приложений, где колбэк сидит на колбэке и колбэком погоняет, причём принимают эти колбэки параметры, тип которых может меняться в зависимости от положения звёзд.
>Проблема с TypeScript и Dart в том, что всё-равно приходится взаимодействовать с JS-библиотеками.Это не проблема. Проблема это написание велосипедов по любому поводу. Где баг на баге и багом погоняет.
Если бы вместо миллионного нового языка и миллиардного переписывая элементарных библиотек на этот новый язык, занялись бы полировкой существующего кода. Эх.
Допустимы оба варианта. Чаще всего явные типы нужны для аргументов функций, их в Julia легко задать. Остальное почти всегда выводится из контекста (аля auto в C++).
Для фанатов БДСМ давно хаскель придумали.
Julia очень простой язык. Её модель гораздо прозрачнее питона.
Обожаю когда беспомощность языка оправдывают "простотой"
>Обожаю когда беспомощность языка оправдывают "простотой"Все люди разные.
Кто-то высокий, кто-то карлик. Кто-то умный, кто-то не очень.
Создавать языки программирования только для умных - отвратительная дискриминация и пережиток прошлого.
> Обожаю когда беспомощность языка оправдывают "простотой"Итнересно, что уважаемый Эксперт Опеннета понимает под "беспомощностью" и "простотой"?
И ASM по этой классификации, ЯП сложный или беспомощный?
А так же php, где нынче type hints стали хорошим тоном
Много вы в продакшене видели хорошего кода?
Пока язык не заставляет ставить типы никто из практикующих программистов ставить их и не будет.
А в PHP есть generic-типы?
У Julia есть явная декларация типа. Можно полностью динамически использовать, можно декларировать. Собственно, хочешь скорость - надо декларировать.arr = Float64[]
function test(arr::Array{Float64,1})
...
end
> Динамическая типизация = язык "для накидать чего-нибудь по-быстрому на коленке".Язык для технических вычислений - это и есть язык "для накидать чего-нибудь по-быстрому на коленке".
А вот для настоящих вычислений в Юльке можно и потипизировать, и пооптимизировать - уже после того, как накидал по-быстрому и на коленке. Поэтому там есть и то и другое.
>Язык для технических вычислений - это и есть язык "для накидать чего-нибудь по-быстрому на коленке".Вы ракеты Союз проектируете?
Нет, боинги. Это имеет какое-то отношение к теме?
Это труселя такие?
> Динамическая типизация = язык "для накидать чего-нибудь по-быстрому на коленке".Динамическая типизация = возможность строить ветвление в зависимости от типа пришедшего на вход параметра.
Динамическая типизация = ускорение разработки на порядки за счёт отсутствия необходимости слежения за типами (функцию не надо переопределять для других типов, она будет съедена интерпретатором и так).Динамическая типизация -- это вопрос выбора. Это вундервафля такая. Если обращаться с ней неаккуратно, можете ногу себе оттяпать. Но если ваши конкуренты большие, сильные и уже давно на рынке -- то почему бы и нет? Иначе-то вы в пролёте.
>Динамическая типизация = возможность строить ветвление в зависимости от типа пришедшего на вход параметра.Эпический бред. Обработку того же JSON-а поддерживают как статические так и динамические языки.
>Динамическая типизация = ускорение разработки на порядкиАга. На сто тыщь порядков.
>за счёт отсутствия необходимости слежения за типами (функцию не надо переопределять для других типов, она будет съедена интерпретатором и так).Шаблоны в статических языках уже запретили?
>Динамическая типизация -- это вопрос выбора.Засунуть в нос карандаш -- это вопрос выбора.
>Это вундервафля такая.Посещению люрка уменьшает IQ на 20%
>Но если ваши конкуренты большие, сильные и уже давно на рынке -- тоони в 90% случаев используют языки со статической типизацией. И скорее всего это java/c#.
>Иначе-то вы в пролёте.С модными/хипстерскими языками без библиотек/инструментов и сообщества вы в пролете по умолчанию.
>> Динамическая типизация = возможность строить ветвление в зависимости от типа пришедшего на вход параметра.
> Эпический бред. Обработку того же JSON-а поддерживают как статические так и динамические языки.Наверное потому, что в вопросе парсинга JSON-а типизация непричём. Зато очень к месту упоминание, что лексический анализатор можно написать на языке с любой типизацией.
>> за счёт отсутствия необходимости слежения за типами (функцию не надо переопределять для других типов, она будет съедена интерпретатором и так).
> Шаблоны в статических языках уже запретили?Шаблоны в C++ -- это адская боль. Подебажте их на досуге.
> они в 90% случаев используют языки со статической типизацией. И скорее всего это java/c#.
> С модными/хипстерскими языками без библиотек/инструментов и сообщества вы в пролете по умолчанию.Опровержение того, чего я не утверждал, видимо льстит Вашему самолюбию? )
2018 год, это когда в качестве примеров статически типизированных языков приводят Typescript и Dart 2.
В больших проектах не от этого сплошной геморрой, а от того, что большие проекты часто строят методом костылей и подпорок, без хорошо продуманной идеологии и интерфейсов. Или в процессе разработки идеологию ломают. В результате, если типизированные языки ещё как-то сдерживают лавинообразное нарастание хаоса в большом проекте, то динамические для этого предоставляют благодатную почву.
Соглашусь, лишь с тем замечанием, что есть как работать с проблемой "предоставляют благодатную почву".
В компилируемых языках с проблемами такого рода борются компиляторы. К сожалению и компиляторы не совершенны, и так же постоянно совершенствуются как и статические анализаторы для динамический типизированных языков. Проблемы высокого уровня к сожалению стабильно не умеют отлавливать ни на каком уровне (race condition, ошибки логики(нужны тесты) и т.д.).По мере совершенствования навыков в нашей профессии, приходит понимание, что не простое это дело заниматься программированием в производстве. И почему нам так много платят (относительно)
Race condition нужно ещё постараться сделать при использовании STM, ошибки логики отлаживаются статически в языках с зависимыми типами.Другое дело, конечно, что для этого всего нужно чуть больше фундаментальных знаний.
Не справедливое замечание. Python давно обзавелся аннотированием типов, ровно так как и в Typescript. Согласился бы про "для накидать чего-нибудь по-быстрому на коленке", но Python в стеке таких проектов как Instagram, Dropbox и YouTube (сейчас в меньшей мере), опровергает Ваши утверждения. Javascript хоть не строго типизированный язык без объявления типов (пока, дело за стандартизацией), но количество успешных и крупных проектов на нем тоже не мало. Успешность проекта зависит от знании и навыков разработчиков большей мере, чем особенности языка.
Кто хочет изучать Julia, скажу, что аннотация типов тут присутствует. Так что можно брать на вооружение в 21 веке. Есть по крайней мере 2 статических анализатора.Прошу прощения, если замечание показалось хоть сколько нибудь резким. Сам программирую преимущественно на Python, Clang и Golang, и в "священных воинах" за идеальные языки не участвую
Я тоже так думал, но существование Clojure и Erlang просто ставит в тупик с такой точкой зрения. Поэтому я уже неделю как погрузился в Clojure и не уйду пока не получу ответы на самый главный вопрос в программировании.
Сегодня вроде не первое апреля, но только вчера 0.6 ветка была стабильной, как сегодня 1.0 уже стабильная версия, а 0.7 предыдущий стабильны
Ну конференция же сейчас проходит :)0.7 была доступна уже как минимум месяц
>Ну конференция же сейчас проходит :)Смузи поят?
К сожалению, нет возможности проверить лично.http://juliacon.org/2018/all_talks.html
https://www.youtube.com/user/JuliaLanguage/featured
Ну я в курсе про конференцию, если внимательно следить за материалами, то ничего сверхнового не было там представлено. В основном обновления по проектам, которые уже существуют. Ветка 0.7, строго говоря, для скачивания доступна была давным-давно. Вот только она была нестабильной веткой до вчерашнего дня, когда внезапно зарелизили версию 1.0.
0.7 давно была заявлена как отличающаяся от 1.0 только поддержкой deprecated API. Ну и, RC-0.7 уже тоже больше месяца. Видимо, решили ускорить процесс миграции. Впрочем, себе 1.0 поставлю где-нибудь через месяц, когда основные библиотеки причешут. Чувствую, что конкретно сейчас, будут некоторые проблемы совместимости.
Спасибо за ответ! Тоже посижу пока на 0.6.
Пожалуй, самый ожидаемый язык для машинного обучения. Сейчас, после стабилизации API, можно говорить о массовом начале использования.
А зачем для МО какой-то особый язык? В том то и соль, что там меньше времени уходит на программирование и больше - на подготовку данных и обучение.
Сейчас в MO чаще всего используют несколько языков. Суть Julia - пишешь на ней и не пишешь на C, C++ и пр. То есть она удобна как для интеграционных вещей, типа данные подготовить, таблички прочитать, строки преобразовать. Так и для реальной математики.
>Сейчас в MO чаще всего используют несколько языков.Из которых 99% - питон.
>Суть Julia - пишешь на ней и не пишешь на C, C++ и пр.Никто переписывать tensirflow/kerras/pytorch и тд на хулию не будет, поезд давно ушел.
>То есть она удобна как для интеграционных вещей, типа данные подготовить, таблички прочитать, строки преобразовать.Знаете что еще более удобно? Более 9000 готовых библиотек на питоне любого уровня, отлаженных и поддерживаемых.
> Из которых 99% - питон.Если проводить опрос среди питонистов - да. А так - R и C, на котором все библиотеки для питона и написаны.
> Никто переписывать tensirflow/kerras/pytorch и тд на хулию не будет, поезд давно ушел.
Предусмотрено. https://github.com/JuliaPy/PyCall.jl
Ну и, к тому же tensorflow/flux/...
А также https://github.com/JuliaInterop/RCall.jl , https://github.com/JuliaInterop/MATLAB.jl и пр.
> Знаете что еще более удобно? Более 9000 готовых библиотек на питоне любого уровня, отлаженных и поддерживаемых.
Библиотеки нужны только конкретные. Они на Julia уже есть. Плюс совместимость для сторого кода. То есть смысла писать на питоне больше нет вообще.
Ну и не забывайте о главной проблеме питона. Хочешь новый алгоритм - пиши на C. В случае Julia это делать не надо.
>Если проводить опрос среди питонистов - да. А так - R и C, на котором все библиотеки для питона и написаны.
>в разрезе MO ака машинного обученияОтсутствие CUDA в списке говорит, что пациент вообще не в теме.
>Предусмотрено. https://github.com/JuliaPy/PyCall.jlЗакопайте ЭТО обратно.
>Библиотеки нужны только конкретные. Они на Julia уже есть. Плюс совместимость для сторого кода. То есть смысла писать на питоне больше нет вообще.Прилетайте в нашу вселенную. Хотя лучше, нет.
>Хочешь новый алгоритм - пиши на C. В случае Julia это делать не надо.Вот тут согласен. Писать на хулии не надо.
И опять же "алгоритм" на "С" ... дай угадаю, 2 курс максимум?
Никто из практикующих программистом так коряво не выражается.
Опять же в разрезе ML "алгоритмы"... Kernell-ы? Они на CUDA.
> И опять же "алгоритм" на "С" ... дай угадаю, 2 курс максимум?Уважаемый аноним(31) с 1-го курса, не знающий, что такое "алгоритм" и "программирование".
Flux и tensorflow используют GPU. Зачем писать напрямую на CUDA - я не знаю. Библиотеки, копирующие интерфейс типовых питоновых библиотек, либо прямо их использующие, на Julia также в изобилии написаны.
Касаемо питона, его поезд, действительно ушел. За 30 лет так и не смогли устранить основные проблемы языка и решить проблему скорости. Нынешний хайп спадёт по мере перехода на Julia учебных заведений. А на ней уже довольно много кто читает курсы.
В части разработки высокопроизводительных сервисов под ML, сейчас Julia нет альтернатив. Julia одинаково пригодна как для интерактивной работы с данными в Jupiter Notebook, так и, собственно, для написания сервисного кода.
После выхода стабильной версии 1.0, крайне вероятно, что поток разработок сильно увеличится. Она и так уже используется практически во всех крупных исследовательских лабораториях и компаниях, работающих в области ML и AI.
>В части разработки высокопроизводительных сервисов под ML, сейчас Julia нет альтернатив.Лучшая шутка трэда! :)
А в реальность нет ни одного "высокопроизводительных сервисов под ML" на этом убер ёзыге ...
> Касаемо питона, его поезд, действительно ушел.а мужики то и не в курсе
> Если проводить опрос среди питонистов - да.Т.е. так бы сделали вы, задавшись вопросом о положении дел в отрасли?
> А так - R и C, на котором все библиотеки для питона и написаны.
R используется реже питона. Ну а пассаж про C - означает что вы фактически ничего не знаете про положение дел в этом вашем Julia. Таки да, в математических потрохах у него C и Fortran. А вы думали за 6 лет десяток хипстеров вам перепишут математические библиотеки с историей близкой к полувеку?
> Предусмотрено. https://github.com/JuliaPy/PyCall.jl
Ну а куды-ж они без этого денутся-то? Ведь, внезапно, для визуализации данных в "превосходно подходящем" языке - питон требуется дергать...
> Плюс совместимость для сторого кода.
О... Вот ты какой, северный олень. Тогда у питона - "совместимость" с C, не меньше. ctypes, cffi - все дела.
> Ну и не забывайте о главной проблеме питона. Хочешь новый алгоритм - пиши на C.
Основная проблема питона - малообразованные детки, которых подкупила простота этого языка. Освоив в лучшем случае туториал - они почему-то уже не стесняются выдавать подобные пассажи, как говорил, классик - космической глупости.
> R используется реже питона. Ну а пассаж про C - означает что вы фактически ничего не знаете про положение дел в этом вашем Julia. Таки да, в математических потрохах у него C и Fortran. А вы думали за 6 лет десяток хипстеров вам перепишут математические библиотеки с историей близкой к полувеку?Вот не лень ли рассуждать о проблемах, которые Вы не знаете? Хотя бы взглянули бы на экосистему Julia, состав рекомендуемых библиотек и их возраст, прежде чем писать абстрактные рассуждения, почти наверняка не написав ни одну математическую функцию.
> Ну а куды-ж они без этого денутся-то? Ведь, внезапно, для визуализации данных в "превосходно подходящем" языке - питон требуется дергать...
Для визуализации в Julia несколько своих собственных библиотек, плюс R, плюс питоновские. Питоновские имеет смысл использовать только в процессе миграции, чтобы было "как привыкли".
> О... Вот ты какой, северный олень. Тогда у питона - "совместимость" с C, не меньше. ctypes, cffi - все дела.
Совместимость старого кода для Julia - это всего лишь возможность сделать мягкую миграцию с R и питон. И С тут ни при чём. Конечно, фанатикам бессмысленно приводить аргументы в виде тестов и пр. Но реальность такова, что питон (для математики) и R - устарели. А замена им - Julia.
> Вот не лень ли рассуждать о проблемах, которые Вы не знаете? Хотя
> бы взглянули бы на экосистему Julia, состав рекомендуемых библиотек и их
> возраст, прежде чем писать абстрактные рассуждения, почти наверняка не написав ни
> одну математическую функцию.Вьюнош, Вы серьезно?
Вы бы хоть в ихний ридми с требованиями к зависимостям заглянули. Внезапно, они такие же как и у numpy, например (ну, кроме дополнительного для работы со строками или поддержки BigInt).
>> Ну а куды-ж они без этого денутся-то? Ведь, внезапно, для визуализации данных в "превосходно подходящем" языке - питон требуется дергать...
> Для визуализации в Julia несколько своих собственных библиотек, плюс R, плюс питоновские.
> Питоновские имеет смысл использовать только в процессе миграции, чтобы было "как привыкли".В общем, по-умолчанию - дергают "устаревший" питон.
>> О... Вот ты какой, северный олень. Тогда у питона - "совместимость" с C, не меньше. ctypes, cffi - все дела.
> Совместимость старого кода для Julia - это всего лишь возможность сделать мягкую
> миграцию с R и питон.Я вам объясняю, возможность дернуть код на другом языке - есть не только для Julia. Почему вдруг в Julia это стало "мягкой миграцией с" - боюсь, без консультации с вашим личным психиатром я не пойму.
> Конечно, фанатикам бессмысленно приводить аргументы в виде тестов и пр.
Заметьте, вы сами признались фанатиком, за язык я вас не тянул.
> Но реальность такова, что питон (для математики) и R - устарели. А
> замена им - Julia.Реклама - это не реальность.
> Вьюнош, Вы серьезно?Абсолютно
> В общем, по-умолчанию - дергают "устаревший" питон.
Если они не будут его дёргать, то обеспечить совместимость с унаследованным кодом, очевидно, невозможно.
>> Но реальность такова, что питон (для математики) и R - устарели. А замена им - Julia.
> Реклама - это не реальность.Сидите на чём хотите. Со мной работать вы точно не будете. И в моей компании - тоже.
>> Вьюнош, Вы серьезно?
> АбсолютноНу, значит вы настолько глупы как кажетесь.
>> В общем, по-умолчанию - дергают "устаревший" питон.
> Если они не будут его дёргать, то обеспечить совместимость с унаследованным кодом,
> очевидно, невозможно.Это просто прекрасно. Вот у нас "превосходно подходящий" для визуализации данных язык. Который, внезапно, для этой самой визуализации дергает код, написанный на "неподходящем" языке. Делающий, собственно, всю работу.
Че тут происходит, зачем нам для запуска пользовательского кода на Julia (!) - вся эта байда на неправильном Питоне? А совместимость обеспечиваем. От кого вы этой пользовательский код унаследовали, болезный? Что-ж за язык-то такой уникальный, что для обеспечения совместимости с "унаследованным" на этом языке кодом необходимо дергать библиотеки на совершенно постороннем языке?
>>> Но реальность такова, что питон (для математики) и R - устарели. А замена им - Julia.
>> Реклама - это не реальность.
> Сидите на чём хотите. Со мной работать вы точно не будете. И
> в моей компании - тоже.Аллилуйя. Я в области рекламы и не работаю. С детьми тоже.
> фанатикам бессмысленно приводить аргументы в виде тестов и пр.Хотелось бы услышать мнение по поводу обсуждений тестов. Вот хдесь есть коротенький разбор их тестирования:
ailev.livejournal.com/1377277.html?nojs=1&thread=15185661А так же рассказ что в ответ на письма авторы улии ничего не отвечают. Создается мнение что результат люди рисуют сами, немного мошенническими способами.
Комментарии?
Это как играть в шахматы с голубем. К тому же, данный гражданин вроде уже "улетел"...
Какая-то прямо новая религия начала по всем распространяться. Верую в бенчмарки и блоги интернетовские. И с светом в глазах несу правду по форумам.
> Динамическая типизацияПовбывав бы!
матлаб непригоден для какого-либо использования.
Ну не скажи. Если надобно быстро проверить работоспособность сложного алгоритма, самое то.
"Быстро" и matlab - не часто эти два слова встретишь в таком контексте :) Однопоточный интерпретатор априрои небыстр, к сожалению :(
1 во-первых gnu octave is blazing fast, так как не интерпретатор.
2 во-вторых с "быстро" действительно проблемы, так как некоторые вещи, встроенные во все нормальные яп, напр конвертация числа в различные системы счисления и обратно, в octave начисто отсутствуют, и приходится писать свои. в r кстати тоже. Язык высокого уровня без таких элементарных вещей в стандартной библиотеке - не язык, а говно.
3 в третьих многое делается через жопу и вас ждут долгие часы отладки и непонимания, почему ваша векторизованная запись операции не работает, хотя вроде бы абсол
тно корректная.
4 octave постоянно крешится.
5 нет батареекрезультат - надо юзать питон.
Не надо путать «быстро разработал» и «быстро выполнил».Вот у нас сейчас так:
1. Учоный профессор изобретает новую идею.
2. мнс-аспирант реализует эту идею в виде прототипа на матлабе. Это месяц.
3. Вместе они отлаживают алгоритм, чтобы он работал нормально. Это ещё три-шесть месяцев.
4. снс или кто покруче переписывает алгоритм на нормальном языке, как правило на С, чтобы можно было им пользоваться на нормальных компьютерах, как правило кластере CUDA.
Так вот, на втором этапе матлаб действительно быстр, если там использовать С, то вместо месяца будем ждать пару лет.
Плюс ко всему, часто идея учоного является доработкой к уже опубликованному алгоритму, а уже опубликованный алгоритм, как правило, имеет опубликованную реализацию в матлабе, которую остаётся только скопипастить и добавлять своего. Копипастить же код на С — довольно плохая идея.
такое впечатление что каждый новичок пытается отхватить кусок пирога и штампует языки как раньше штамповали ветки линуксов.
Julia создана под вполне конкретную нишу - математика. В этой нише из opensource наработок был только R. Octave оказался мертворожденным. Питон не пригоден в силу медленности и ограниченности синтаксиса. Поэтому сделали новый язык. Matlab и Wolfram вряд ли сейчас готовы бесплатно выложить свои наработки. Бесплатных и открытых конкурентов в этой области ей сейчас нет.
Octave это не отдельный язык, это свободный клон матлаба.
Это не клон, а попытка реализовать матлаб. Но она провалилась.А вот в Julia проблемы скорости и надёжности решены. В то же время, нет проблем с полнотой математических библиотек. За 6 лет, как минимум, типовой набор уже реализовали
> надёжности
> говорит о надежности в языке который используют три с половиной тела.Надежная Хулия - надежна. Неуловимы Джо - неуловим.
> надёжности
> динамическая типизацияНе смешите мой копчик.
>Julia создана под вполне конкретную нишу - математика.R уже давно создан, велосипеды и троллейбусы из буханок не нужны.
ничего, что у R скорость на пару порядков ниже?
>ничего, что у R скорость на пару порядков ниже?Маня пытаются блеснуть словцом "порядок" в качестве числительноно.
>> Маня пытаются блеснуть словцом "порядок" в качестве числительноно.тесты посмотрите. Может быть, местами, ошибся. Не пару, а тройку порядков.
Последний тест
Python 2.2921 37.4429 224.4362
Julia 2.769 44.333 345.069
Закапывайте.
Такое сравнение надо в помойку отправить. Problem 3 - перемножение матриц. Julia выигрывает на порядок у C (как GCC, так и Intel Compiler). Сказано, в предисловии что все зависит от библиотек. По умолчанию в Julia используется OpenBlas. Кто мешал в примере вызвать эти же функции в сишном коде? Либо во всех случаях применять самую оптимизированную библиотеку - Intel MKL, - которую использует MATLAB, чтобы провести корректное сравнение. А так пишем, что сравниваем языки, а в итоге библиотеки, которые к тому же частично на Фортране написаны. Ну абсурд же.
Scilab забыли. А мне его синтакис показался удобнее, чем у матлаба. Правда его тоже еще допиливать надо((
> Julia создана под вполне конкретную нишу - математика.Численные методы. Это, мягко говоря, не вся математика, даже близко.
> В этой нише из opensource наработок был только R. Octave оказался мертворожденным.
В этой нише opensource наработок - хоть обмазывайся. И R, и пара клонов matlab'а, и python+numpy&co, про зиллионы строк открытого кода на C/Fortran я даже не заикаюсь.
> Питон не пригоден в силу медленности и ограниченности синтаксиса.
Что, у очередного гуру отступы чешутся?
> Бесплатных и открытых конкурентов в этой области ей сейчас нет.
Детки прячутся от других людей, закрывая собственные глазки - лет до трех. Дальше творить подобное, даже в подростковом возрасте - это уже явные проблемы с задержкой развития...
> Детки прячутся от других людей, закрывая собственные глазки - лет до трех. Дальше творить подобное, даже в подростковом возрасте - это уже явные проблемы с задержкой развития...Ну так выйдите из 3-х летнего возраста, выделите объективные критерии и сравните технологии. Что только писать об абстрактных альтернативах и проблемах развития, если альтернатив реально не видно? Естественно, если мы говорим не о средствах для школьников/студентов, а о реальных production ready продуктах.
Если чего-то не знаете, то это не недостаток того самого "чего-то". А лишь ваша проблема, что "не знаете". Эту проблему можно устранить, а можно продолжать рассказы про подростков, детей с развитием и пр. Выход прост - возьмите и посмотрите. А ещё лучше - проверьте.
> Что только писать об абстрактных альтернативах и проблемах развития, если
> альтернатив реально не видно?Вам пальцем показали на конкретные проекты, существование которых вы просто проигнорировали. Причем тут какие-то абстрахтные проблемы развития?
> Вам пальцем показали на конкретные проекты, существование которых вы просто проигнорировали. Причем тут какие-то абстрахтные проблемы развития?Вот когда научитесь аргументы приводить в виде конкретных критериев и циферок, а не пальцем показывать, тогда и продолжим. А сейчас - идите и учитесь. Для приличия, изучите хотя бы ещё один язык программирования, кроме питона.
>> Вам пальцем показали на конкретные проекты, существование которых вы просто проигнорировали. Причем тут какие-то абстрахтные проблемы развития?
> Вот когда научитесь аргументы приводить в виде конкретных критериев и циферок, а
> не пальцем показывать, тогда и продолжим.Что-то не увидел у вас никаких циферок. Полагал, что учусь у лучшего. Таки нет, вы просто балабол?)
> Динамическая типизация: язык не требует явного определения типов для переменных по аналогии со скриптовыми языками программирования.Насколько мне известно, смысл динамической типизации в том, что переменная имеет всегда один тип. А явное определение типа не признак статической типизации.
Похоже на трудности перевода и напридумывание, потому что на главной странице сайта:
> Julia has a rich language of descriptive datatypes, and type declarations can be used to clarify and solidify programs.
> Насколько мне известно, смысл динамической типизации в том, что переменная имеет всегда один тип. А явное определение типа не признак статической типизации.Смысл динамической типизации в том, что переменная вообще не имеет типа. Тип есть у значения переменной.
В Julia объектная модель, хоть и простая, но есть. Есть универсальный тип Any. Однако можно указать значение какого типа должна принимать переменная (или потомка этого типа). Впрочем, сейчас это сделано для аргументов функций и при инициализации. Глобальные переменные типизировать нельзя.
Скорее всего, это требование оптимизации. Чтобы можно было выделить память под массивы с числами нужного размера, а не ссылки на ссылки.
> Смысл динамической типизации в том, что переменная вообще не имеет типа. Тип есть узначения переменной.
Откуда вы такое взяли? Можно источник? Потому что не вижу смысла в этих словах.
По вашей логике у всех переменных в динамических языках всегда один тип -- ссылка на объект.
А "тип значения переменной" для меня эквивалентно "тип переменной".
> По вашей логике у всех переменных в динамических языках всегда один тип -- ссылка на объект.Обычно так и есть. В противном случае будут проблемы с выделением памяти под значение
И какой размер в памяти занимает переменная, если она не ссылка и хранит любой объект внутри себя? Тоже "любой"?
В динамических языках переменные это именно что ссылки на объекты
> И какой размер в памяти занимает переменная, если она не ссылка и
> хранит любой объект внутри себя? Тоже "любой"?
> В динамических языках переменные это именно что ссылки на объектыВы с кем разговариваете / кому отвечаете?
Вам. По ветке не очевидно?
Просто вы сказали то же самое, что и я.> В динамических языках переменные это именно что ссылки на объекты
> По вашей логике у всех переменных в динамических языках всегда один тип -- ссылка на объект.Это был мой ответ на
> Смысл динамической типизации в том, что переменная вообще не имеет типа.
Я имел в виду, что переменные имеют один тип, во-первых. Во-вторых, отсюда следует вывод, что это статическая типизация. Исходя из логики первого комментария.
Я, в свою очередь, отвечал на Вашу реплику: "По вашей логике у всех переменных в динамических языках всегда один тип -- ссылка на объект". Всё так и есть. И тип объекта и тип переменной - это разные вещи. Переменная всегда имеет один тип - "ссылка на объект". Но вот объекты либо имеют разные типы (когда объектная можель построена на классах), либо не имеют типа вообще (когда объектная модель построена на прототипах, как в SELF).
>> Смысл динамической типизации в том, что переменная вообще не имеет типа.
>Я имел в виду, что переменные имеют один тип, во-первых. Во-вторых, отсюда следует вывод, что это статическая типизация. Исходя из логики первого комментария.Если переменная имеет тип, конторый не определён в пространстве языка программирования, то, считайте, что у неё нет типа. В динамических языках программирования, как правило, нет типа "чистая ссылка". Поэтому фраза, что "переменная не имеет типа", в целом, корректна.
Не знаю, где это взял аноним, но у меня такие сведения отсюда: https://books.google.hu/books?id=4pgQfXQvekcC&pg=PT248&lpg=P...
> Names have no types... Because variables have no types...Я считаю, что это для более легкого понимания так написали.
https://en.wikipedia.org/wiki/Variable_(computer_science)
> In computer programming, a variable ... is a storage location (identified by a memory address) paired with an associated symbolic name (an identifier), which contains some known or unknown quantity of information referred to as a value. The variable name is the usual way to reference the stored value, in addition to referring to the variable itself, depending on the context.
a = 1
На низком уровне идентификатор `a` привязан к адресу в памяти, к-й содержит указатель на некий объект класса `int`. И так со всеми переменными. Т.е. все переменные являются указателями -- имеют тип, причем один и тот же на протяжении их жизни. Что, по сути, является признаком статической типизации, если придраться.
Если же рассуждать, что тип переменной это указатель and/or тип объекта, на который указатель ссылается, то тоже нельзя говорить, что имена/переменные не имеют типов.
Ну мы же про динамическую типизацию.
>> Names have no types... Because variables have no types...
> Я считаю, что это для более легкого понимания так написали.Сильно зависит от того, что понималось под 'variable' в том контексте.
> На низком уровне идентификатор `a` привязан к адресу в памяти, к-й содержит
> указатель на некий объект класса `int`. И так со всеми переменными.Да, Вы правы, что все имена связываются с участками памяти через указатели. Разница лишь в том, когда происходит разыменование имени в указатель. В компилируемых языках зачастую разыменование происходит на этапе компиляции, и когда Вы, например, собрали программку на C, ей для выполнения уже и не нужно знать, что данная область памяти была в исходном коде связана с неким именем `a`. Правда, можно сохранять эти имена (их называют дебаг-символами) для отладочных нужд. В интерпретируемых языках эти имена придётся сохранять в любом случае.
> Т.е. все переменные являются указателями -- имеют тип, причем один и
> тот же на протяжении их жизни. Что, по сути, является признаком
> статической типизации, если придраться.Да, разница между статической и динамической типизациями заключена как раз в том, может ли связывание имени и типа меняться вместе с контекстом выполнения.
> Да, разница между статической и динамической типизациями заключена как раз в том, может ли связывание имени и типа меняться вместе с контекстом выполнения.Рад , что в этом мы согласны. И жаль, что столько сообщений ушло в другом направлении.
Возвращаясь к моему первому комментарию.
> - Динамическая типизация: язык не требует явное определение типов для переменных по аналогии со скриптовыми языками программирования. Поддерживается интерактивный режим работы;
Текст представлен так, что признаком динамической типизации является необязательность явного определения типов для переменных.
Но это неправда. Похоже, что автор решил "помочь" своими объяснениями, хотя в оригинале этого нет.
> Although one sometimes speaks of dynamic languages as being "typeless", they are definitely not: every object, whether primitive or user-defined, has a type. The lack of type declarations in most dynamic languages, however, means that one cannot instruct the compiler about the types of values, and often cannot explicitly talk about types at all. In static languages, on the other hand, while one can – and usually must – annotate types for the compiler, types exist only at compile time and cannot be manipulated or expressed at run time. In Julia, types are themselves run-time objects, and can also be used to convey information to the compiler.
>> Да, разница между статической и динамической типизациями заключена как раз в том, может ли связывание имени и типа меняться вместе с контекстом выполнения.
> Рад , что в этом мы согласны. И жаль, что столько сообщений ушло в другом направлении.Ну там много чего наложилось. Опечатки вон те же.
Но суть-то, конечно, была правильная. Вид типизации не коррелирует с необходимостью указывать типы. Вон тот же ocaml -- статически типизирован, но типы указывать не обязательно настолько, что их как правило не пишут вообще нигде.
А вот вопрос: есть ли динамически типизированный язык, где всегда надо указывать типы?
> Текст представлен так, что признаком динамической типизации является необязательность
> явного определения типов для переменных.Угу, двоеточие там лишнее. Надо бы точкой заменить. Предложите правку. Целый тред борьбе за неё посвятили. ))
> А вот вопрос: есть ли динамически типизированный язык, где всегда надо указывать типы?Интересно. Особенно интересно узнать мотивацию такого, если такое есть.
> Although one sometimes speaks of dynamic languages as being "typeless", they are definitely not: every object, whether primitive or user-defined, has a type.
Кажется, я опечатался.Надо было
> смысл статической типизации в том, что переменная имеет всегда один тип.
Либо
> смысл динамической типизации в том, что переменная может менять тип.
> Кажется, я опечатался.Суть не в опечатке. Суть в том, что в выбранных Вами терминах легко заблудиться. Попробуйте выкинуть из головы такую странную вещь, как переменная -- этот термин вообще говоря неправильный и есть много его самых разных определений.
Мыслите, отталкиваясь от понятия связывания. Это упростит размышления:
- статически типизированные языки запрещают изменение типа связывания
- динамически типизированные языки разрешают его смену
Что значит тип связывания?
> Что значит тип связывания?Ну смотри, свзявывание -- это соответствие между именем и тем, что имя обозначает. То, что имя обозначает -- это по сути значение и его тип. В каждый момент времени связывание имеет только один тип.
Тип может описываться в разных языках по-разному. Самое важное -- это то, что тип позволяет однозначно определить сущность значения, и как с ним работать. Очень часто описание типа начинается с пространства имён, к которому относится значение. Это может быть пространство имён функций и данных (его также называют пространством имён переменных, внезапно, почему и говорю, что термин перегружен). В таблице с пространством имён данных содержится описание данного типа (например, если это структура, скажем, то какие у неё есть поля и т.п.), в таблице с пространством имён функций описывается её код, а также хранится кадр стека, в котором функция была создана (для организации лексического поиска и замыканий).
В динамически типизированных языках всякий раз при вычислении какого-либо имени прямо в рантайме ты проходишь по всем этим таблицам. Это, безусловно, занимает некоторое время и тормозит работу программы. В статически типизированных языках часть этой работы перекладывается на компилятор. В них эти таблицы могут и вовсе не существовать в рантайме -- они будут нужны только на этапе сборки. Это в целом ускоряет программу, но также делает её разработку менее гибкой.
Есть задачи, где гибкость более важна. Например символьные вычисления (Wolfram Mathematica и Maxima). Например, когда скорость разработки важнее гарантированного отсутствия багов, которые могут возникнуть в результате ошибок проектирования -- в этом случае проектировать систему надо очень осторожно, поэтому крупные компании стараются с этим не связываться, но для стартапа, который хочет конкурировать с гигантами, это если не единственно разумный, то как минимум вполне уместный вариант (Viaweb).
Вы путаете динамическую типизацию и вывод типов. Вывод типов = статическая типизация.
> Вы путаете динамическую типизацию и вывод типов.Я думаю, что и Вы тоже путаете вывод типов и необходимость указывать тип.
> Вывод типов = статическая типизация.
Строго говоря, это не совсем так. Это свойство просто обычно обсуждается в контексте строгой статической типизации. Другое дело, я понимаю, что если человек когда-либо видел, ну например, что-нибудь из семейства ML, то за вывод типов меньшее считать уже не хочется.
Тем не менее, ну вот берёте Вы скриптовый язык типа php. И вот допустим Вы пишете `a=1` или `a="1"`. Он же определит, что `a` в первом случае имеет тип int, а во втором -- string. Это тоже ведь в некотором смысле вывод типов, как-никак.
PS: Вон в Scala, говорят, тоже есть "вывод типов". Почитайте, в каком виде, посмеётесь. Тем не менее это -- вывод типов. ))
>Компилятор Julia основан на наработках проекта LLVMЛучше бы он не видел свет.
> Кроме стабилизации языка в Julia 1.0 также представлено несколько новшеств, среди которых новый встроенный пакетный менеджер Pkg, позволяющий не только манипулировать репозиториями и устанавливать пакеты и связанные с ними зависимости, но и создавать привязанные к проектам окружения пакетов, записывать и воссоздавать состояние работающего приложения,О боги! Зачем это в язык-то?
А это "all batteries included", как в питон. Бег по граблям, надцатая версия.
rubygem или Module Dependency in Java 9 не смущают? Именно здесь пакетный менеджер вызывает вопросы?
Не смущают, а вызывают тот же вопрос: к языку это зачем пристёгивать?
позволяет избежать анархии в развитии языка
Похоже, у Вас незамутнённыое знанием интуитивное понимание "анархии".В предлагаемой парадигме "развития языка" это ведёт к неконторолируемому
автором проекта X внешнему (по отношению к X) воздействию на проект.
Джулия всем была бы хороша, но без отладчика её полезность стремится к бесконечно малой величине.
Консольные - есть. Встроены.Для отладки автономных скриптов, конечно, полезно иметь интегрированный в редактор отладчик, но не смертельно и без него. А в Юпитере это не столь важно.
> Консольные - есть. Встроены.Родная документация о них молчит. Или вы тут подразумевали gdb?
> Для отладки автономных скриптов, конечно, полезно иметь интегрированный в редактор отладчик,
> но не смертельно и без него.И без теплого клозета в квартире тоже не смертельно.
>> Консольные - есть. Встроены.
> Родная документация о них молчит. Или вы тут подразумевали gdb?Наш любимый gdb с Джулией не работает.
Почему? Работает, ежели вы C код собрались отлаживать.Но, боюсь - это сильно не то, что хотелось вопрошавшему о возможностях отладки.
> Почему? Работает, ежели вы C код собрались отлаживать.Уж, С то и Фортран мы отладим, не переживайте. Вот как код Джулии отлаживать? Неужто как один написал на тематическом форуме в уме представлять как работает код и отладчик становится не нужен?
Ну да, а в другом уме - изобразить виртуальную машину, на которой ваш код работает. И компьютер тоже будет не нужен!
Скорее Джулия будет не нужна. По крайней мере без отладчика. В общем пока будем писать на Питоне с критическими местами на С и Фортране.
> Наш любимый gdb с Джулией не работает.Как раз он и использовался - https://docs.julialang.org/en/release-0.7/devdocs/debuggingt...
>> Наш любимый gdb с Джулией не работает.
> Как раз он и использовался - https://docs.julialang.org/en/release-0.7/devdocs/debuggingt...Не из той оперы. Это для отладки вызываемого С кода.
debugging Julia's C code название подраздела об этом говорит.
> Консольные - есть. Встроены.Ссылку в студию. Галлиум не в счет, ибо давно почил в бозе.
https://www.youtube.com/watch?v=UuABHGlDj5o
> https://www.youtube.com/watch?v=UuABHGlDj5oDelete Gallium 9 months ago Это последний коммит в галлиум на гитхабе.
Отладчик в атоме не поддерживает точек останова. По факту дебаггера для Джулии нет. Так, что используем вечный Фортран с переменным первым индексом массива и отладкой в гдб.
https://www.youtube.com/watch?v=KuM0AGaN09s
> https://www.youtube.com/watch?v=KuM0AGaN09sА это что-то новенькое. Точки останова поддерживает?
Да уш. Модно-молодежно. Ссылка сразу на кину на ютубчике.
В 1.0 рекомендовано использовать https://github.com/jrevels/Cassette.jl
Я, например, использую простую отладочную печать. Не сказал бы, чтобы приходилось что-то монструозное на Julia отлаживать. Впрочем, подобный метод я использую и для многих других скриптовых языков. Просто привычка.
И эти люди говорят, что Julia - наше все, а Питон устарел?!
> И эти люди говорят, что Julia - наше все, а Питон устарел?!А какая связь между устареванием питона и пошаговым отладчиком в Julia?
Питон (и R) - устарели, за Julia - будущее. Причем тут связь? Никакой связи нету - настоящим пацанам отладчики не нужны!
> Никакой связи нету - настоящим пацанам отладчики не нужны!зависит от задач. Во многих случаях, действительно, отладочной печати достаточно.
> Питон (и R) - устарели, за Julia - будущее
ок
> одной из ключевых целей проекта является достижение производительности близкой к программам на языке Си.А чо, джава уже догнала и перегнала ;)
Это да, они в свое время на ассемблер замахивались. :)
хороший компилятор уже давно делает код лучше, чем то, что может написать руками средний ассемблист. Слишком много особенностей в современных процессорах.