Началась конференция JuliaCon 2016
Основная дизайн-цель языка Julia (http://julialang.org/) -- это решить "проблему двух языков" в численных методах (когда прототипировать алгоритмы и скриптовать удобно на языке высокого уровня, а потом требуется переходить на более низкоуровневый язык, чтобы всё работало быстро, в том числе параллельно). Сегодня у любителей Julia праздник, идёт ежегодный смотр достижений JuliaCon: http://juliacon.org/abstracts.html. В России на Julia пишут в бОльших объёмах, чем можно подумать (группа ВКонтакте тут: https://vk.com/julialanguage, но я встречал многих, кто на Julia пишет, не зная о существовании ни этой группы, ни каких-то других).
Расползается Julia по миру сегодня главным образом через университеты: http://julialang.org/teaching/ (MIT при этом один из ведущих по числу курсов - относительно свежая информация тут: https://github.com/stevengj/julia-mit). Это всё не курсы собственно Julia, они не по линии computer science, это курсы главным образом каких-то разделов численных методов, а Julia просто занимает место какого-нибудь Python, MATLAB/Octave или R. Обычно курсы выглядят как ноутбуки в Jupyter (бывший IPython), Ju в этом Jupyter как раз от Julia, это родной теперь для этого проекта язык: http://jupyter.org/. Административно Julia в NumFocus -- http://ailev.livejournal.com/1203522.html.
В языке прямо сейчас идёт опережающее развитие суперкомпьютерного функционала (http://docs.julialang.org/en/latest/manual/parallel-computing/ -- это просто документация языка, http://www.nextplatform.com/2016/01/26/dirt-simple-hpc-making-the-case-for-julia/ -- этот крен в HPC уже заметили «железячники», http://julialang.org/blog/2016/03/parallelaccelerator -- это специализированный для Julia ускоритель от Intel Labs, и много всяких "обёрток" типа https://github.com/JuliaComputing/ArrayFire.jl для работы с массивами в GPU).
Пакетов там уже больше тысячи, что, конечно, капля в море -- http://pkg.julialang.org/. Базовой математики там тьмы и залежи, есть какие-то сообщества на каждую тему: см. разные ссылки в http://julialang.org/community/. Несмотря на то, что Julia отлично цепляет любые сишные библиотеки как родные (и сама, кстати, может в них компилироваться, прикидываясь сями -- типа "пишу высокоуровнево, а код будет для чужих выглядеть сишной библиотекой"), сообщество честно переписывает на Julia основную математику, добиваясь заявленной цели: полный контроль в одном языке над всем стеком выполнения программы -- от прикладного уровня до железа, включая библиотеки. Никаких непоняток на границе сишного кода, код до дна будет Julia.
Эти ребята сейчас переписывают в версии 0.5 реализацию массивов: делают дополнительное ускорение за счёт опционального отключения проверки индексов, «всё для скорости, всё для победы». Кто из численников начинает программировать, те полны восторгов. Кто из традиционных computer science программистов - те крутят носом, и по понятным причинам: это не функциональный, не объект-ориентированный, не акторный язык, совсем не похож на Rust, Golang, Scala и прочих фаворитов нынешней моды классического языкостроения. И в нём multiple dispatch как базовая парадигма, а объект-ориентированность и функциональность доступны как расширения языка. Вот что даёт multiple dispatch: http://nbviewer.jupyter.org/gist/StefanKarpinski/b8fe9dbb36c1427b9f22. Я подробней писал про решение expression problem с помощью multiple dispatch и приводил на эту тему ссылки тут: http://ailev.livejournal.com/1218155.html
Расширяемость языка идёт как важнейшее свойство, второе после multiple dispatch: интроспецкция (код программы это данные для неё) и метапрограммирования (язык принципиально расширяемый, в нём доступна кодогенерация времени исполнения -- http://docs.julialang.org/en/latest/manual/metaprogramming/), идеи впрямую вытащены из Лиспа. Так что Julia -- это совсем не фортран и не паскаль, и даже не матлаб, хотя жутко на них похож. По мощности он ближе к Питону, хотя отличается от Питона во всём (писать на Julia чуток более высокоуровнево и поэтому компактно, чем на Питоне, а скорость получающегося кода -- сишная, а не питонная).
Дальше нужно смотреть: смогут ли инженеры воспользоваться Julia. Инженеры в массе своей объект-ориентированием и функциональщиной уже доказали, что без спецтренинга пользоваться не могут, их потолок -- матлаб и Питон без объект-ориентированности, так что поглядим, как они смогут справиться с Julia.
В принципе, можно было бы на эту тему даже какие эксперименты сделать, найти «когнитивное сродство инженеров к разным парадигмам программирования». И может оказаться по результатам замеров (какой-нибудь cognitive load, например), что Julia тут будет получше прочих. Ну, или не оказаться. Моя гипотеза, что multiple dispatch в основе языка для инженеров проще, чем объект-ориентированность и функциональность. А обслуживающие инженеров программисты всегда смогут воспользоваться средствами метапрограммирования для расширения языка.
У меня самого пара идей с Julia (вряд ли они имеют шанс на реализацию, но лучше сразу написать):
1. Учебное применение по информатике. Я понял, что учебных курсов с достаточным числом задач по computer science нет: всё заканчивается сотнями "олимпиадных задач" с автоматической проверкой. Нужно:
а) добавить автоматическую проверку для Julia
б) настрогать необходимое число "неолимпиадных" учебных задач, чтобы добиться "беглости" без перегруза учителя с проверкой решений (про "беглость" -- это Алан Кей тут: http://ailev.livejournal.com/461928.html).
После этого можно думать об использовании Julia в школе и ВУЗе для текущих нужд информатики -- вместо текущих Си++, Паскаля и очень редко Питона.
2. Учебное физмат применение. Конечно, как для Wolfram Language есть Mathematica, как для Python есть Sage, для Julia нужно сделать какой-то вариант символьной математики. В простейшем виде её уже прикручивают болтами из Питона (http://mth229.github.io/symbolic.html), но хочется "родной" привязки -- и затем можно делать на Julia решение задач по курсам уже математики-физики (с той же автоматизированной проверкой). Пока же смотреть и пускать слюну на http://www.wolframalpha.com/pro/problem-generator/ и довольствоваться Jupyther notebook текущих вузовских курсов по численным методам. Хотя в принципе, это не только в ВУЗе можно использовать, но и в школах для поддержки физики-математики.
3. Инженерное применение: реализовать на Julia функционал акаузальной симуляции мультифизики, похожий на Modelica (http://modelica.org/), но не объект-ориентированный. При этом сразу получаем силу математических пакетов Julia: оптимизацию, параллельные вычисления на бэк-энде, веб-фреймворки и визуализацию данных, notebooks и т.д.. Плохая реализация численных методов -- это то, чем страдают все реализации Modelica, кроме самой дорогой. Вот и решить эту проблему. А дальше идти по той же линии, что и Modelica: в языки архитектуры и описания требований. Julia ведь расширяемый язык! Глядишь, по этой линии можно и опять к SysMoLan вернуться как языку моделеориентированной системной инженерии (сейчас этот функционал делается на паре связанных объект-ориентированных языков: Modelica+SysML).
Конечно, есть и какие-то идеи про deep learning. Текущие работы по реализации алгоритмов на Julia (mocha.jl) были свёрнуты после выхода десятка крупных хорошо поддержанных ресурсами фреймворков. Конечно, Julia отлично оборачивает в себя и сишные, и питонные интерфейсы -- там и mxnet можно найти (разработчики mocha переметнулись на оборачивание его), и TensorFlow, и всё что угодно. Пока нет какой-то особой архитектурной идеи, я бы не ожидал развития родных нейроалгоритмов на Julia. Но я думаю, что по мере роста сложности нейроархитектур (в сторону всех этих памятей-внимания-деревьев и end-to-end differentiable структур) и по мере роста числа готовых численных пакетов тут тоже могут появиться инициативы. Так что на эту тему я думаю, но проекта не предлагаю.
Расползается Julia по миру сегодня главным образом через университеты: http://julialang.org/teaching/ (MIT при этом один из ведущих по числу курсов - относительно свежая информация тут: https://github.com/stevengj/julia-mit). Это всё не курсы собственно Julia, они не по линии computer science, это курсы главным образом каких-то разделов численных методов, а Julia просто занимает место какого-нибудь Python, MATLAB/Octave или R. Обычно курсы выглядят как ноутбуки в Jupyter (бывший IPython), Ju в этом Jupyter как раз от Julia, это родной теперь для этого проекта язык: http://jupyter.org/. Административно Julia в NumFocus -- http://ailev.livejournal.com/1203522.html.
В языке прямо сейчас идёт опережающее развитие суперкомпьютерного функционала (http://docs.julialang.org/en/latest/manual/parallel-computing/ -- это просто документация языка, http://www.nextplatform.com/2016/01/26/dirt-simple-hpc-making-the-case-for-julia/ -- этот крен в HPC уже заметили «железячники», http://julialang.org/blog/2016/03/parallelaccelerator -- это специализированный для Julia ускоритель от Intel Labs, и много всяких "обёрток" типа https://github.com/JuliaComputing/ArrayFire.jl для работы с массивами в GPU).
Пакетов там уже больше тысячи, что, конечно, капля в море -- http://pkg.julialang.org/. Базовой математики там тьмы и залежи, есть какие-то сообщества на каждую тему: см. разные ссылки в http://julialang.org/community/. Несмотря на то, что Julia отлично цепляет любые сишные библиотеки как родные (и сама, кстати, может в них компилироваться, прикидываясь сями -- типа "пишу высокоуровнево, а код будет для чужих выглядеть сишной библиотекой"), сообщество честно переписывает на Julia основную математику, добиваясь заявленной цели: полный контроль в одном языке над всем стеком выполнения программы -- от прикладного уровня до железа, включая библиотеки. Никаких непоняток на границе сишного кода, код до дна будет Julia.
Эти ребята сейчас переписывают в версии 0.5 реализацию массивов: делают дополнительное ускорение за счёт опционального отключения проверки индексов, «всё для скорости, всё для победы». Кто из численников начинает программировать, те полны восторгов. Кто из традиционных computer science программистов - те крутят носом, и по понятным причинам: это не функциональный, не объект-ориентированный, не акторный язык, совсем не похож на Rust, Golang, Scala и прочих фаворитов нынешней моды классического языкостроения. И в нём multiple dispatch как базовая парадигма, а объект-ориентированность и функциональность доступны как расширения языка. Вот что даёт multiple dispatch: http://nbviewer.jupyter.org/gist/StefanKarpinski/b8fe9dbb36c1427b9f22. Я подробней писал про решение expression problem с помощью multiple dispatch и приводил на эту тему ссылки тут: http://ailev.livejournal.com/1218155.html
Расширяемость языка идёт как важнейшее свойство, второе после multiple dispatch: интроспецкция (код программы это данные для неё) и метапрограммирования (язык принципиально расширяемый, в нём доступна кодогенерация времени исполнения -- http://docs.julialang.org/en/latest/manual/metaprogramming/), идеи впрямую вытащены из Лиспа. Так что Julia -- это совсем не фортран и не паскаль, и даже не матлаб, хотя жутко на них похож. По мощности он ближе к Питону, хотя отличается от Питона во всём (писать на Julia чуток более высокоуровнево и поэтому компактно, чем на Питоне, а скорость получающегося кода -- сишная, а не питонная).
Дальше нужно смотреть: смогут ли инженеры воспользоваться Julia. Инженеры в массе своей объект-ориентированием и функциональщиной уже доказали, что без спецтренинга пользоваться не могут, их потолок -- матлаб и Питон без объект-ориентированности, так что поглядим, как они смогут справиться с Julia.
В принципе, можно было бы на эту тему даже какие эксперименты сделать, найти «когнитивное сродство инженеров к разным парадигмам программирования». И может оказаться по результатам замеров (какой-нибудь cognitive load, например), что Julia тут будет получше прочих. Ну, или не оказаться. Моя гипотеза, что multiple dispatch в основе языка для инженеров проще, чем объект-ориентированность и функциональность. А обслуживающие инженеров программисты всегда смогут воспользоваться средствами метапрограммирования для расширения языка.
У меня самого пара идей с Julia (вряд ли они имеют шанс на реализацию, но лучше сразу написать):
1. Учебное применение по информатике. Я понял, что учебных курсов с достаточным числом задач по computer science нет: всё заканчивается сотнями "олимпиадных задач" с автоматической проверкой. Нужно:
а) добавить автоматическую проверку для Julia
б) настрогать необходимое число "неолимпиадных" учебных задач, чтобы добиться "беглости" без перегруза учителя с проверкой решений (про "беглость" -- это Алан Кей тут: http://ailev.livejournal.com/461928.html).
После этого можно думать об использовании Julia в школе и ВУЗе для текущих нужд информатики -- вместо текущих Си++, Паскаля и очень редко Питона.
2. Учебное физмат применение. Конечно, как для Wolfram Language есть Mathematica, как для Python есть Sage, для Julia нужно сделать какой-то вариант символьной математики. В простейшем виде её уже прикручивают болтами из Питона (http://mth229.github.io/symbolic.html), но хочется "родной" привязки -- и затем можно делать на Julia решение задач по курсам уже математики-физики (с той же автоматизированной проверкой). Пока же смотреть и пускать слюну на http://www.wolframalpha.com/pro/problem-generator/ и довольствоваться Jupyther notebook текущих вузовских курсов по численным методам. Хотя в принципе, это не только в ВУЗе можно использовать, но и в школах для поддержки физики-математики.
3. Инженерное применение: реализовать на Julia функционал акаузальной симуляции мультифизики, похожий на Modelica (http://modelica.org/), но не объект-ориентированный. При этом сразу получаем силу математических пакетов Julia: оптимизацию, параллельные вычисления на бэк-энде, веб-фреймворки и визуализацию данных, notebooks и т.д.. Плохая реализация численных методов -- это то, чем страдают все реализации Modelica, кроме самой дорогой. Вот и решить эту проблему. А дальше идти по той же линии, что и Modelica: в языки архитектуры и описания требований. Julia ведь расширяемый язык! Глядишь, по этой линии можно и опять к SysMoLan вернуться как языку моделеориентированной системной инженерии (сейчас этот функционал делается на паре связанных объект-ориентированных языков: Modelica+SysML).
Конечно, есть и какие-то идеи про deep learning. Текущие работы по реализации алгоритмов на Julia (mocha.jl) были свёрнуты после выхода десятка крупных хорошо поддержанных ресурсами фреймворков. Конечно, Julia отлично оборачивает в себя и сишные, и питонные интерфейсы -- там и mxnet можно найти (разработчики mocha переметнулись на оборачивание его), и TensorFlow, и всё что угодно. Пока нет какой-то особой архитектурной идеи, я бы не ожидал развития родных нейроалгоритмов на Julia. Но я думаю, что по мере роста сложности нейроархитектур (в сторону всех этих памятей-внимания-деревьев и end-to-end differentiable структур) и по мере роста числа готовых численных пакетов тут тоже могут появиться инициативы. Так что на эту тему я думаю, но проекта не предлагаю.