• Julia: типы, мультиметоды и арифметика над полиномами
    +1
    julia> a(x::Any, b::Float64) = nothing
    a (generic function with 1 method)
    
    julia> a(b::Float64, t::Any) = 1
    a (generic function with 2 methods)
    
    julia> methods(a)
    # 2 methods for generic function "a":
    [1] a(x, b::Float64) in Main at REPL[1]:1
    [2] a(b::Float64, t) in Main at REPL[2]:1
    
    julia> a(1.0, 1.0)
    ERROR: MethodError: a(::Float64, ::Float64) is ambiguous. Candidates:
      a(b::Float64, t) in Main at REPL[2]:1
      a(x, b::Float64) in Main at REPL[1]:1
    Possible fix, define
      a(::Float64, ::Float64)
    Stacktrace:
     [1] top-level scope at none:0

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


    Possible fix, define
      a(::Float64, ::Float64)
  • Julia: типы, мультиметоды и арифметика над полиномами
    +1

    У Julia есть абстрактные и конкретные типы. Абстрактные всегда пустые, но могут наследоваться. Конкретные могут инстанцироваться и иметь поля. Для любого метода можно указать либо тип, к которому его конкретно надо примениять, либо указать, что тип абстрактный, и применять к любому из потомков.


    То есть, ответ — полиморфизм статический. Однако методы для обработки наших типов можем писать где угодно. Обычно вместе с определением типа. Шаблоны C++ или Java generics — это, как раз, наиболее близкий аналог.

  • Julia: типы, мультиметоды и арифметика над полиномами
    +1

    Конкретно в этом примере код перегружен. Вопрос о причинах — к автору. Циклы в Julia используются редко. В большинстве случаев они заменяются применением функции к итератору. Например:


    function mag(p::NDimPoint)
        sqrmag = 0.0
        # т.к. размерность точно неизвестна, нужно итерировать по всем полям структуры
        # имена полей для типа T получаются вызовом fieldnames(T)
        for name in fieldnames(typeof(p))
            sqrmag += getfield(p, name)^2
        end
        return sqrt(sqrmag)
    end

    скорее встретится в форме:


    mag(p::NDimPoint) = 
        sqrt(sum(name -> getfield(p, name)^2, fieldnames(typeof(p)))

    Или


    mag(p::NDimPoint) = 
        sum(name -> getfield(p, name)^2, fieldnames(typeof(p)) |>
        sqrt
  • Julia. Веб-сервисы
    0
    Вы не пробовали какие-то замеры делать по производительности именно веб-сервисов?

    Не пробовал. О чём честно написал в заключении.

    Чтобы результаты были корректные, мало запускать только тесты на Julia. Надо в одинаковых условиях сравнивать с эталонными реализациями.

    Идеальный вариант — встраиваться в существующие бенчмарки и прогонять на них.
  • 6 нежданчиков от Джулии
    +1
    Если структура декларируется как structure, то она по-умолчанию неизменяема. Если mutable structure, то изменяема. Система типов у Julia несколько отличается от привычных императивных языков. Но довольно простая.

    Ну и на счёт возвращаемых значений. В норме функция именно возвращает новое значение, а не модифицирует входные аргументы. Такой подход и в Ruby, кстати.

    А вариант функции с модификацией, когда надо изменить именно тот массив, который передан на вход, автоматически означает, что имя функции будет с суффиксом `!`.
  • 6 нежданчиков от Джулии
    +1
    list = [1 2 3]
    for item in list
    item = item + 1
    end


    У Julia всё просто. Воспринимаем переменную как ссылку на объект, но помним, что большинство операций не изменяют исходный объект (чистые функции и всё такое....). Соответственно, этот пример — бесполезен. item — локальная переменная. item + 1 не изменяет объект, на который ссылалась item.
    julia> list = [1 2 3]
    1×3 Array{Int64,2}:
     1  2  3
    
    julia> for item in list
             item = item + 1
           end
    
    julia> list
    1×3 Array{Int64,2}:
     1  2  3


    А вот такой пример приведёт к модификации (метод с суффиксом `!` является модифицирующим):
    julia> list = [[1],[2],[3]]
    3-element Array{Array{Int64,1},1}:
     [1]
     [2]
     [3]
    
    julia> for item in list
             push!(item, 1)
           end
    
    julia> list
    3-element Array{Array{Int64,1},1}:
     [1, 1]
     [2, 1]
     [3, 1]


    И такой пример также приведёт к модификации по той же причине. item ссылается на автономные объекты-массивы, каждый из которых может быть изменён:
    julia> list = [[1],[2],[3]]
    3-element Array{Array{Int64,1},1}:
     [1]
     [2]
     [3]
    
    julia> for item in list
                item .+= 1
           end
    
    julia> list
    3-element Array{Array{Int64,1},1}:
     [2]
     [3]
     [4]


    Касаемо оптимизаций Julia на граничных значениях циклов — не отвечу. Скорее всего, что-то делает. В сущности, у неё есть возможность посмотреть генерируемый LLVM-код. По нему можно проверить.
  • 6 нежданчиков от Джулии
    +1
    Итерация в for происходит по ссылке или по значению?

    Я не совсем понимаю вопрос. Даже в C++ — итератор — отдельный класс. В Julia нет таких языковых понятий как ссылка и значение. Любое присвоение следует воспринимать как копирование ссылки (это не так на уровне машинного кода, но справедливо для модели языка). C-шных операторов &a, *a здесь тоже нет.

    Правильно ли я понимаю что если использовать встроенные функции языка типа map, то там проверка индексов опускается?

    Опять не понимаю вопрос. Если вопрос о том, выполняется ли реально внутренняя проверка, когда мы пишем a[i], чтобы i не вылетел за пределы, то ответ — не знаю. Скорее всего, не проверяется. Иначе на это придётся тратить процессорное время. Но при работе с итератором всегда идёт вычисление следующего элемента с проверкой границы.

    Собственно, в примерах выше, я всего лишь продемонстрировал как избегать использование прямого обращения по индексу, чтобы не ошибиться с границами индексов. Это, конечно, ещё не Руби с его Enumerable. Но уже далеко не C++, с его довольно ограниченными итераторами.
  • 6 нежданчиков от Джулии
    +2
    using BenchmarkTools
    
    y = 1 : 0.5 : 10000000
    x = zeros(length(y))
    b = @benchmark begin
      x .= y .+ y      # in-place addition
      x .= 2 .* y      # in-place multiplication
    end
    
    #BenchmarkTools.Trial: 
    #  memory estimate:  192 bytes
    #  allocs estimate:  3
    #  --------------
    #  minimum time:     117.716 ms (0.00% GC)
    #  median time:      127.008 ms (0.00% GC)
    #  mean time:        133.613 ms (0.00% GC)
    #  maximum time:     194.349 ms (0.00% GC)
    #  --------------
    #  samples:          38
    #  evals/sample:     1

    y = [1 : 0.5 : 10000000...]
    x = zeros(length(y))
    b2 = @benchmark begin
      x .= y .+ y      # in-place addition
      x .= 2 .* y      # in-place multiplication
    end
    
    #BenchmarkTools.Trial: 
    #  memory estimate:  96 bytes
    #  allocs estimate:  4
    #  --------------
    #  minimum time:     59.379 ms (0.00% GC)
    #  median time:      62.218 ms (0.00% GC)
    #  mean time:        66.322 ms (0.00% GC)
    #  maximum time:     132.069 ms (0.00% GC)
    #  --------------
    #  samples:          76
    #  evals/sample:     1
  • 6 нежданчиков от Джулии
    0
    julia> x = 1 : 0.5 : 10
    1.0:0.5:10.0
    
    julia> typeof(x)
    StepRangeLen{Float64,Base.TwicePrecision{Float64},Base.TwicePrecision{Float64}}

    julia> x = [1 : 0.5 : 10...]
    19-element Array{Float64,1}:
      1.0
      1.5
      2.0
      2.5

    Не везде это будет работать, где может быть использован массив.


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

  • Python vs. Scala для Apache Spark — ожидаемый benchmark с неожиданным результатом
    +1
    Если нужен Spark и уже знаете Java — разумнее всего сделать полшага вперед и перейти на Scala. Если конечно это прагматический вопрос, а не религиозный.


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

    Для нынешнего Java-кода я могу быть уверен, что найду программистов и через 10 лет. Для Scala — не факт, что и через 5 лет такие найдутся. Тем более, что то, что пишут на Java для Spark, по факту, синтаксически не сильно отличается от Scala.
  • Python vs. Scala для Apache Spark — ожидаемый benchmark с неожиданным результатом
    +2
    Ну если проект на Spark, то тут даже думать не надо. Любой вариант кроме Scala требует экстраординарных обоснований.


    Запустите опрос о том, кто и на чём на Spark пишет.

    Да и, вопрос, если BigData, то Spark ли… И стоит для Ignite или Flink использовать что-то кроме Java?..
  • Python vs. Scala для Apache Spark — ожидаемый benchmark с неожиданным результатом
    0
    В настоящее время Scala практически не развивается. Именно потому, что Java за последние 10 лет довольно сильно изменилась в лучшую сторону, и возникает вопрос, зачем нужна Scala. Да и остались ли, хоть какие-то API у Spark (как, впрочем, и у любого другого BigData-инструмента), которые не были бы на 100% совместимы с Java?

    PS: Я бы не решился сейчас начинать новый проект на Scala. Опыт её использования имеется. Очень дорого обходится в ней контроль за кодом разработчиков. Существенно проще написать write-only код, по сравнению с Java. + чисто скальные проблемы по интеграции разных библиотек, собранных в разных Скалах.
  • Python vs. Scala для Apache Spark — ожидаемый benchmark с неожиданным результатом
    +1
    Здесь бы было интересно сравнить также vanilla Java-код. И получить ответ на вопрос, стоит ли мучаться с поиском программистов под Scala ради экономии 10% объема кода.
  • 6 нежданчиков от Джулии
    +2

    У программистов на императивных языках программирования есть привычка использовать избыточные конструкции. Однако в Julia можно многие из них не использовать. Например индексы массива. Очень часто они вообще не нужны. Либо индексы могут быть вычислены автоматически (без необходимости вспоминать, с нуля они начинаются или с единицы). Например, традиционный вариант цикла:


    let res = 0
      x = [1:0.5:10...] # массив от 1 до 10 с шагом 0.5
      for i = 1 : length(x)
        res = res + 1 / x[i]
      end
      println(res) # 5.195479314287365
    end

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


    let res = 0
      x = [1:0.5:10...]
      for item in x
        res = res + 1 / item
      end
      println(res) # 5.195479314287365
    end

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


      x = [1:0.5:10...] 
      res = mapreduce(item -> 1/item, +, x)
      println(res) # 5.195479314287365

    Имя метода здесь — mapreduce, значит аргументы им соответствют. Функция item -> 1/item относится к map. Функция + — к reduce.


    Для случая простой свёртки без map, можем просто использовать reduce.


    Если же действительно нужен индекс, то можно заставить Julia взять его самостоятельно.


    let res = 0
      x = [1:0.5:10...]
      for i in eachindex(x)
        res = res + i / x[i]
      end
      println(res) # 32.80452068571264
    end

    Но в примере видим, что нас интересовал индекс и элемент, а не индекс для того, чтобы взять элемент. Значит можем заменить код:


    let res = 0
      x = [1:0.5:10...]
      for (i, item) in enumerate(x)
        res = res + i / item
      end
      println(res) # 32.80452068571264
    end

    Но и в этом случае нас не просили писать цикл, а просили вычилить результат по каждому индексу и элементу. Значит, можем заменить на:


      x = [1:0.5:10...]
      res = mapreduce(((i, item),) -> i/item,  +,  enumerate(x))
      println(res) # 32.80452068571264

    В последнем примере конструкция ((i, item),) указывает, что надо разобрать первый аргумент из tuple.

  • Julia. Генераторы отчётов и документации
    +1
    Julia может использоваться как полноценный скриптовый язык. Но подключение библиотек у неё — довольно длительная процедура.

    Если нужна скорость, то на Julia лучше писать сетевые сервисы, которые вообще не выгружаются из памяти и делают что-либо по запросу.
  • Другой GitHub: репозитории по Data Science, визуализации данных и глубокому обучению
    +1
    В последний раздел забыли добавить Flux.jl с примерами model-zoo
  • Субъективное видение идеального языка программирования
    +1
    (-2..5).select(&:even?).map { |x| x < 0 ? x**3 : x**2 }

    56 символов. И читаемость никуда не пропала.

  • Субъективное видение идеального языка программирования
    +2

    К вопросу о лёгкой читаемости кода на питоне....


    Это Ruby, если что...


    list_b = [-2, -1, 0, 1, 2, 3, 4, 5].select(&:even?).map { |x| x < 0 ? x**3 : x**2 }

    А это Julia:


    list_a = [-2, -1, 0, 1, 2, 3, 4, 5]
    list_b = map(x -> x < 0 ? x^3 : x^2,  filter(iseven, list_a))

    list_a = [-2, -1, 0, 1, 2, 3, 4, 5]
    list_b = filter(iseven, list_a) |> list -> map(x -> x < 0 ? x^3 : x^2, list)

    list_a = [-2, -1, 0, 1, 2, 3, 4, 5]
    list_b = filter(iseven, list_a) |> 
             list -> map(list) do x
                x < 0 ? x^3 : x^2
             end

    И во всех случаях всё прозрачно. Либо читаем последовательно, либо разворачиваем скобки в порядке вложенности.

  • Как фрилансеру выйти из тени и начать платить налоги
    +1
    Про процесс получения дохода в валюте — это всё понятно. Вопрос вызвала фраза: «можно не подавать никаких деклараций». Как это возможно, если при любом раскладе получается доход, не соответствующий виду деятельности по патенту?
  • Как фрилансеру выйти из тени и начать платить налоги
    +1
    Плюсы. Если ИП не ведет никакой деятельности, кроме той, на которую куплен патент — можно не подавать никаких деклараций. Заплатил взнос и стоимость патента, и на этом все.


    А что делать с валютными доходами на патенте? Налог на курсовую разницу при любых обменах начисляется на УСН, даже если платёж получен по патенту. Аналогично про процент, начисленный банком по открытым счетам.
  • Julia. Скрипты и разбор аргументов командной строки
    0
    Лично для себя, думаю, что чаще всего буду использовать docopt. По программисткой привычке обычно открываю скрипт, прежде чем запустить. В docopt описание гарантированно будет написано именно так, как оно предлагается пользователю. В прочих случаях описание надо либо дублировать (почти наверняка не будет полностью соответствовать), либо надо читать размазанную таблицу argparse (дублирование документации тоже не исключено). argparse vs docopt — это, скорее, вопрос важности автоматической валидации типов.
  • Julia. Работа с таблицами
    +1
    Условно интерактивные диаграммы можно строить в Jupiter Notebook.
    docs.juliaplots.org/latest/examples/plotlyjs, plot.ly/julia, randyzwitch.com/ECharts.jl/box

    У графиков Plotly будут скроллеры, зум и пр. Также DataFrame при выводе в Notebook отображается со скроллерами. Но только первые и последние строки.

    На счет статьи по интерактивному интерфейсу, до нового года взяться не готов. У меня по плану в этом году — генераторы статических отчетов и веб-сервисы. Думаю, нам надо заводить клуб джулиистов и распределять интересные темы по авторам :)
  • Julia. Работа с таблицами
    0
    Нет пошагового дебаггера. Пока нет. Ожидается, что появится на базе github.com/jrevels/Cassette.jl

    Откровенно говоря, пошаговый отладчик — это вопрос привычки. Отладочная печать типа "@show" и "@debug" доступна в любом случае. А если разрабатываете в Atom/Juno, то есть возможность запустить выделенный фрагмент кода. Когда разрабатываете плоский скрипт, где используется минимум вложенных функций, то проблем нет вообще. Просто выделяете кусок кода и запускаете. Или вбиваете код в REPL, который находится тут же в среде разработки. Сессия со всеми переменными сохраняется до тех пор, пока её явно не перезапустите. То есть работает всё очень быстро. Плюс Juno отображает все выставленные переменные. Сложнее, когда надо отлаживать модули с большим количеством функций. Но и тут, вопрос лишь в стиле написания кода и его адаптации под отладку без пошагового отладчика. Например та самая рекомендация, что функции должны быть короткими. А их запуск в любом случае будет прописан из юнит-теста (в норме, все модули обязаны их иметь), который можно запускать из Juno.
  • Оформить ИП — единственный путь
    0
    Не стоит демонизировать налоговую. Безусловно, область получения зарплаты на иностранные счета — это серая область законодательства. Никто в налоговой не знает что с этим делать. Слишком мала база для этого. Тем не менее:
    1. Гражданам РФ запрещено получать валютные переводы от иностранцев на счета физ. лиц в РФ
    2. Гражданам РФ НЕ запрещено работать за пределами РФ.
    3. Получение зарплаты от иностранных компаний в этом случае возможно лишь на иностранные же счета


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

    Также формально нигде не сказано, что лицо, которое работает на иностранную компанию, не имеет права делать это с территории РФ. Налоговая не проверяет сроки пребывания за границей, поскольку не связана с миграционной службой. Однако, если доходы есть, а за границей не был, то это может вызвать вопросы. Если же за границей находился, то доказать, что там не работал, уже вряд ли кто-то сможет.

    Соответствеено, каким образом налоговая сможет наложить штраф на зарплату, полученную на иностранный счёт (разрешенный тип операции), и как в суде она сможет мотивировать, что это не зарплата? И зачем вообще налоговой ввязываться в это гиблое дело, если можно просто получить 13%? Заметьте, я не рассматриваю неуплату налога. Это уже другая статья, не имеющая отношения к валютному контролю.

    Касаемо сроков пребывания за границей, то расчёт очень прост. Зп программиста $150-200к в год, хотя и не является средней, однако реалистична. Соответственно, если находился за границей месяц, то сумма зп по декларации за год 20-40 тыс. вряд ли вызовет у кого-то вопросы. А если и вызовет, то, опять же, доказать обратное в суде налоговая не сможет. Вопрос чисто порядка сумм.

    Но в любом случае, ИП обходится дешевле, чем уплата налогов с иностранных счетов. Кроме того, открытие иностранных счетов, сама по себе, не самая простая задача.
  • Оформить ИП — единственный путь
    0
    У меня личный опыт того, как это делается.
    «Мужик в прошлом году» получил штраф при переводах между банками РФ. А тут мы обсуждаем получение заработной платы на себя (первый пункт из той самой 12-й статьи) на личные иностранные счета от иностранных компаний. И это не тот случай нарушения валютного законодательства, когда кто-то хочет получить на валютный счёт физ. лица банка РФ некие валютные переводы от иностранных компаний.
    Иностранные банки находятся вне РФ и заморозить что-либо в них по требованию ФНС невозможно. Я согласен с тем, что вопросы возникнуть могут, но, почти уверен, что если суммы более-менее соответствющие заработной плате, претензий у налоговой не будет. Единственное что могут пытаться оспорить — это то, что деньги получены не как заработная плата. Но зачем им это, если Вы добровольно пришли с декларацией доходов.
  • Оформить ИП — единственный путь
    0
    Если находитесь хотя бы месяц в году за пределами РФ, то основнанием получения денег можно декларировать получение заработной платы. Независимо от совпадения или несовпадения даты пребывания за пределами РФ и получением денег. Впрочем, в качестве дополнительно защиты, не стоит переводить эти деньги на свои счета в РФ в текущем году. Подаёте на следующий год декларацию, уплачиваете налог, после этого делаете что хотите.
  • Оформить ИП — единственный путь
    –2
    1. Возможность удаленной работы (перестаем быть налоговым и валютным агентом)
    Для этого надо не находиться ни в одной стране больше 180 дней. Значит как минимум, 3 страны в год. В некоторых странах, для попадания в их налоговые интересы, достаточно и 3 месяца находиться.

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

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

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

    3. В конце-концов можно просто переехать и работать в иностранной компании

    Деньги получать чемоданами? Иначе будете платить по местному законодательству. И это сильно больше 13% с иностранных счетов физ. лица. И сильно больше, чем у ИП…
  • Оформить ИП — единственный путь
    0
    Нет даже ограничения на количество банков. Просто платить придётся за обслуживание в каждом из них.
  • Оформить ИП — единственный путь
    0
    Физ. лицо имеет право иметь иностранные счета. Они должны декларироваться, но право их иметь — есть. На них можно получать доход. Этот доход надо декларировать как доход, полученный на иностранные счета. Собственно, подаёте декларацию как физ. лицо. Налог 13% в переводе на рубли на дни начисления. Обоснование причин получения придумываете сами. Лишь бы все месяцы были закрыты, и суммы в валюте соответствовали выписке с банковского счёта. Перевод обоснования не требуется (проверка — это проблема налоговой). Но, по-большому счёту, их интересуют лишь суммы и даты, а не причины получения денег.

    Причём самое главное — деньги могут оставаться в том банке, куда были начислены. Переводить в РФ их не требуется.

    Недостаток тут только один. 13% в любом случае. Плюс проценты на перевод к нам и потери на конвертации в рубли, если они нужны. В случае ИП, если это не Москва, налог может быть меньше 1% (по патенту).
  • Julia. Работа с таблицами
    0

    По-моему Julia уже достигла зрелости. Именно потому, для задач ML и обработки данных мы решили её использовать. Пару лет назад, вероятно, я бы согласился с python, но сейчас смысла его использования уже нет. Да и примеров уже достаточно. Хотя, в большинстве случаев, их надо искать. Иногда, чтобы понять, как сделать что-то для себя, надо смотреть код библиотек. Но тут — лишь вопрос программистской квалификации и способности быстро понять как оно должно работать. В целом, Julia не является каким-то принципиально новым языком программирования. Это просто переосмысление существующих моделей. Потому начать программировать на ней довольно просто.


    В DevOps, не знаю где использовать… Но если есть задачи типа конвертировать какие-либо json, csv, прочие данные в другой формат, откуда-то прочитать, что-то куда-то загрузить, то она вполне может пригодиться. По крайней мере подобные скриптики мы тоже пытаемся делать.

  • Julia. Работа с таблицами
    +1

    Сейчас уже большинство популярных библиотек перенесли на 1.0. К слову, в Julia очень удобно проверять библиотеки при помощи встроенных тестов. Когда устанавливаете новый пакет, надо всего лишь набрать команду test ИмяПакета. Если всё в порядке, то можно использовать.


    Касаемо графиков. Я использую Plots / GR. Каких-либо проблем сейчас не замечаю. Из прочих бакендов, см. http://docs.juliaplots.org/latest/examples/plotlyjs/ — интерактивные диаграммы для jupyter notebook. Из известных мне проблем, в plotlyjs поломаны полярные координаты. В остальном, работает.


    И относительно того, как рисовать, Yermack написал серию статей, где, как раз, акцент на графику. Собственно, см. хаб https://habr.com/hub/julia/

  • Julia. Работа с таблицами
    +1

    Благодарю за отзыв! Ваши предыдущие статьи, откровенно говоря, и спровоцировали меня на создание учетной записи здесь и на написание этой статьи. Описание по примерам — это хорошо, но только для тех, кому примеры понятны. Для тех же, кому предметная область далека, весь текст может показаться слишком абстрактным, а возможности языка — какими-то надуманными "фичами", которые нужны только тем, кто понимает эту непонятную предметную область. Имено поэтому я и решил изменить контекст изложения и начать делать его в отрыве от предметной области, но с акцентом на то, как программировать. Впрочем, всего должно быть в меру, потому, безусловно, статьи с конкретными примерами тоже нужны и важны.


    Julia — новый язык. На данный момент вряд ли ошибусь, если скажу, что специалистов по ней пока ещё просто нет. Сам я погрузился в Julia в августе, как раз под версию 1.0. До этого только читал обзоры. В следущем году специалисты уже точно будут. Технологии на Julia имеют явный потенциал. Впрочем, как раз сейчас, пытаемся делать сервисы обработки данных именно на Julia.


    Кроме того, мы задумались о создании учебного курса для студентов 1-го курса технического университета, где Julia станет первым языком программирования. Она видится хорошим языком для изучения принципов алгоритмизации, а также в качестве языка для решения текущих студенческих задач.

  • Julia. Работа с таблицами
    +1

    Вопрос про сравнение с pandas я уже слышал… Но главный вопрос — критерии сравнения. Если вопрос про производительность — это сделать можно. Только надо подобрать наборы данных и операции, на которых сравнивать. Если же вопрос про языки запросов типа


    x = @from i in df begin
               @where i.age>50
               @select {i.name, i.children}
               @collect DataFrame
           end

    то это отдельный разговор. См. https://juliadata.github.io/DataFrames.jl/stable/man/querying_frameworks.html


    Касаемо сравнения производительности, почти уверен, что у pandas будет провал в том случае, когда добавляются сложные условия выборки, требующие выполнения питон-кода. У Julia всегда будет выполняться родной код.


    Касаемо сравнения с numpy, тот же вопрос о критериях. Если сравнивать производительность прямо, то см. https://julialang.org/benchmarks/ Но вопрос, на сколько это реалистично отражает практические задачи. Если сравнивать чистые вычисления внутри Julia и внутри numpy, думаю, что для numpy не всё плохо. Если же появляются задачи, где данные надо использовать в нескольких библиотеках, которые не понимают numpy, или просто требуется их перепаковка из numpy-объектов в питон-объекты и обратно, получаются точки провала производительности. У Julia их нет, поскольку везде используется native-код.


    Касаемо синтаксиса с numpy и Matlab, рекомендую посмотреть сравнительную таблицу https://cheatsheets.quantecon.org/


    И компактно представленные средства из Julia — https://juliadocs.github.io/Julia-Cheat-Sheet/


    То есть ответ касаемо случаев использования Julia такой. Если нет унаследованного кода на Питоне, то следует писать на Julia.....

  • Julia. Работа с таблицами
    0
    Идея написать эту статью возникла как результат экспериментов с Julia. Не всем надо решать задачи физики или строить модели машинного обучения, но обработка табличных данных встречается часто. А потому это может стать той самой точкой входа, которая подтолкнёт к исследованию новой технологии.

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