В настоящее время Scala практически не развивается. Именно потому, что Java за последние 10 лет довольно сильно изменилась в лучшую сторону, и возникает вопрос, зачем нужна Scala. Да и остались ли, хоть какие-то API у Spark (как, впрочем, и у любого другого BigData-инструмента), которые не были бы на 100% совместимы с Java?
PS: Я бы не решился сейчас начинать новый проект на Scala. Опыт её использования имеется. Очень дорого обходится в ней контроль за кодом разработчиков. Существенно проще написать write-only код, по сравнению с Java. + чисто скальные проблемы по интеграции разных библиотек, собранных в разных Скалах.
Здесь бы было интересно сравнить также vanilla Java-код. И получить ответ на вопрос, стоит ли мучаться с поиском программистов под Scala ради экономии 10% объема кода.
У программистов на императивных языках программирования есть привычка использовать избыточные конструкции. Однако в 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.
Про процесс получения дохода в валюте — это всё понятно. Вопрос вызвала фраза: «можно не подавать никаких деклараций». Как это возможно, если при любом раскладе получается доход, не соответствующий виду деятельности по патенту?
Плюсы. Если ИП не ведет никакой деятельности, кроме той, на которую куплен патент — можно не подавать никаких деклараций. Заплатил взнос и стоимость патента, и на этом все.
А что делать с валютными доходами на патенте? Налог на курсовую разницу при любых обменах начисляется на УСН, даже если платёж получен по патенту. Аналогично про процент, начисленный банком по открытым счетам.
Лично для себя, думаю, что чаще всего буду использовать docopt. По программисткой привычке обычно открываю скрипт, прежде чем запустить. В docopt описание гарантированно будет написано именно так, как оно предлагается пользователю. В прочих случаях описание надо либо дублировать (почти наверняка не будет полностью соответствовать), либо надо читать размазанную таблицу argparse (дублирование документации тоже не исключено). argparse vs docopt — это, скорее, вопрос важности автоматической валидации типов.
У графиков Plotly будут скроллеры, зум и пр. Также DataFrame при выводе в Notebook отображается со скроллерами. Но только первые и последние строки.
На счет статьи по интерактивному интерфейсу, до нового года взяться не готов. У меня по плану в этом году — генераторы статических отчетов и веб-сервисы. Думаю, нам надо заводить клуб джулиистов и распределять интересные темы по авторам :)
Откровенно говоря, пошаговый отладчик — это вопрос привычки. Отладочная печать типа "@show" и "@debug" доступна в любом случае. А если разрабатываете в Atom/Juno, то есть возможность запустить выделенный фрагмент кода. Когда разрабатываете плоский скрипт, где используется минимум вложенных функций, то проблем нет вообще. Просто выделяете кусок кода и запускаете. Или вбиваете код в REPL, который находится тут же в среде разработки. Сессия со всеми переменными сохраняется до тех пор, пока её явно не перезапустите. То есть работает всё очень быстро. Плюс Juno отображает все выставленные переменные. Сложнее, когда надо отлаживать модули с большим количеством функций. Но и тут, вопрос лишь в стиле написания кода и его адаптации под отладку без пошагового отладчика. Например та самая рекомендация, что функции должны быть короткими. А их запуск в любом случае будет прописан из юнит-теста (в норме, все модули обязаны их иметь), который можно запускать из Juno.
Не стоит демонизировать налоговую. Безусловно, область получения зарплаты на иностранные счета — это серая область законодательства. Никто в налоговой не знает что с этим делать. Слишком мала база для этого. Тем не менее:
Гражданам РФ запрещено получать валютные переводы от иностранцев на счета физ. лиц в РФ
Гражданам РФ НЕ запрещено работать за пределами РФ.
Получение зарплаты от иностранных компаний в этом случае возможно лишь на иностранные же счета
Как следствие, доходы, которые похожи на заработную плату, не будут вызывать вопросы у налоговой. И я не знаю случаев, чтобы кому-то наложили штраф именно за получение зарплаты на иностранный счёт, да и как его потом взять с иностранного же банка.
Также формально нигде не сказано, что лицо, которое работает на иностранную компанию, не имеет права делать это с территории РФ. Налоговая не проверяет сроки пребывания за границей, поскольку не связана с миграционной службой. Однако, если доходы есть, а за границей не был, то это может вызвать вопросы. Если же за границей находился, то доказать, что там не работал, уже вряд ли кто-то сможет.
Соответствеено, каким образом налоговая сможет наложить штраф на зарплату, полученную на иностранный счёт (разрешенный тип операции), и как в суде она сможет мотивировать, что это не зарплата? И зачем вообще налоговой ввязываться в это гиблое дело, если можно просто получить 13%? Заметьте, я не рассматриваю неуплату налога. Это уже другая статья, не имеющая отношения к валютному контролю.
Касаемо сроков пребывания за границей, то расчёт очень прост. Зп программиста $150-200к в год, хотя и не является средней, однако реалистична. Соответственно, если находился за границей месяц, то сумма зп по декларации за год 20-40 тыс. вряд ли вызовет у кого-то вопросы. А если и вызовет, то, опять же, доказать обратное в суде налоговая не сможет. Вопрос чисто порядка сумм.
Но в любом случае, ИП обходится дешевле, чем уплата налогов с иностранных счетов. Кроме того, открытие иностранных счетов, сама по себе, не самая простая задача.
У меня личный опыт того, как это делается.
«Мужик в прошлом году» получил штраф при переводах между банками РФ. А тут мы обсуждаем получение заработной платы на себя (первый пункт из той самой 12-й статьи) на личные иностранные счета от иностранных компаний. И это не тот случай нарушения валютного законодательства, когда кто-то хочет получить на валютный счёт физ. лица банка РФ некие валютные переводы от иностранных компаний.
Иностранные банки находятся вне РФ и заморозить что-либо в них по требованию ФНС невозможно. Я согласен с тем, что вопросы возникнуть могут, но, почти уверен, что если суммы более-менее соответствющие заработной плате, претензий у налоговой не будет. Единственное что могут пытаться оспорить — это то, что деньги получены не как заработная плата. Но зачем им это, если Вы добровольно пришли с декларацией доходов.
Если находитесь хотя бы месяц в году за пределами РФ, то основнанием получения денег можно декларировать получение заработной платы. Независимо от совпадения или несовпадения даты пребывания за пределами РФ и получением денег. Впрочем, в качестве дополнительно защиты, не стоит переводить эти деньги на свои счета в РФ в текущем году. Подаёте на следующий год декларацию, уплачиваете налог, после этого делаете что хотите.
1. Возможность удаленной работы (перестаем быть налоговым и валютным агентом)
Для этого надо не находиться ни в одной стране больше 180 дней. Значит как минимум, 3 страны в год. В некоторых странах, для попадания в их налоговые интересы, достаточно и 3 месяца находиться.
2. Возможность получать деньги без соприкосновения с отечественными банковскими структурами.
Дойчебанк на его родине, например, даже счёт без регистрации по месту жительства не откроет. А для того, чтобы её получить, либо придётся селиться в мелком городе, где отсутствует очередь в соответствующее ведомство, либо будете месяц-другой ждать. Потом надо уведомить при отъезде, чтобы через год проблем не было. Да и справки в банк, всё равно придётся приносить. Иначе любые поступления из не задекларированных источников будут заблокированы.
В США без номера социального страхования большинство банков с Вами даже разговаривать не станет. А его, без постоянной работы и визы с разрешением на работу, никто не выдаст.
В целом, везде есть банки, которые согласятся открыть счёт иностранцу без регистрации. Но надежность сохранения денег под вопросом.
3. В конце-концов можно просто переехать и работать в иностранной компании
Деньги получать чемоданами? Иначе будете платить по местному законодательству. И это сильно больше 13% с иностранных счетов физ. лица. И сильно больше, чем у ИП…
Физ. лицо имеет право иметь иностранные счета. Они должны декларироваться, но право их иметь — есть. На них можно получать доход. Этот доход надо декларировать как доход, полученный на иностранные счета. Собственно, подаёте декларацию как физ. лицо. Налог 13% в переводе на рубли на дни начисления. Обоснование причин получения придумываете сами. Лишь бы все месяцы были закрыты, и суммы в валюте соответствовали выписке с банковского счёта. Перевод обоснования не требуется (проверка — это проблема налоговой). Но, по-большому счёту, их интересуют лишь суммы и даты, а не причины получения денег.
Причём самое главное — деньги могут оставаться в том банке, куда были начислены. Переводить в РФ их не требуется.
Недостаток тут только один. 13% в любом случае. Плюс проценты на перевод к нам и потери на конвертации в рубли, если они нужны. В случае ИП, если это не Москва, налог может быть меньше 1% (по патенту).
По-моему Julia уже достигла зрелости. Именно потому, для задач ML и обработки данных мы решили её использовать. Пару лет назад, вероятно, я бы согласился с python, но сейчас смысла его использования уже нет. Да и примеров уже достаточно. Хотя, в большинстве случаев, их надо искать. Иногда, чтобы понять, как сделать что-то для себя, надо смотреть код библиотек. Но тут — лишь вопрос программистской квалификации и способности быстро понять как оно должно работать. В целом, Julia не является каким-то принципиально новым языком программирования. Это просто переосмысление существующих моделей. Потому начать программировать на ней довольно просто.
В DevOps, не знаю где использовать… Но если есть задачи типа конвертировать какие-либо json, csv, прочие данные в другой формат, откуда-то прочитать, что-то куда-то загрузить, то она вполне может пригодиться. По крайней мере подобные скриптики мы тоже пытаемся делать.
Сейчас уже большинство популярных библиотек перенесли на 1.0. К слову, в Julia очень удобно проверять библиотеки при помощи встроенных тестов. Когда устанавливаете новый пакет, надо всего лишь набрать команду test ИмяПакета. Если всё в порядке, то можно использовать.
Касаемо графиков. Я использую Plots / GR. Каких-либо проблем сейчас не замечаю. Из прочих бакендов, см. http://docs.juliaplots.org/latest/examples/plotlyjs/ — интерактивные диаграммы для jupyter notebook. Из известных мне проблем, в plotlyjs поломаны полярные координаты. В остальном, работает.
И относительно того, как рисовать, Yermack написал серию статей, где, как раз, акцент на графику. Собственно, см. хаб https://habr.com/hub/julia/
PS: Я бы не решился сейчас начинать новый проект на Scala. Опыт её использования имеется. Очень дорого обходится в ней контроль за кодом разработчиков. Существенно проще написать write-only код, по сравнению с Java. + чисто скальные проблемы по интеграции разных библиотек, собранных в разных Скалах.
У программистов на императивных языках программирования есть привычка использовать избыточные конструкции. Однако в Julia можно многие из них не использовать. Например индексы массива. Очень часто они вообще не нужны. Либо индексы могут быть вычислены автоматически (без необходимости вспоминать, с нуля они начинаются или с единицы). Например, традиционный вариант цикла:
Однако в коде видно, что индекс мы не используем по прямому назначению. Значит код может быть переписан как:
Более того, мы же видим, что и цикл, в общем-то с точки зрения того, что требуется получить, является избыточным. Нас интересует результат свёртки массива по операции. Значит можем выразить эти действия лакончиным:
Имя метода здесь —
mapreduce, значит аргументы им соответствют. Функцияitem -> 1/itemотносится кmap. Функция+— кreduce.Для случая простой свёртки без
map, можем просто использоватьreduce.Если же действительно нужен индекс, то можно заставить Julia взять его самостоятельно.
Но в примере видим, что нас интересовал индекс и элемент, а не индекс для того, чтобы взять элемент. Значит можем заменить код:
Но и в этом случае нас не просили писать цикл, а просили вычилить результат по каждому индексу и элементу. Значит, можем заменить на:
В последнем примере конструкция
((i, item),)указывает, что надо разобрать первый аргумент изtuple.Если нужна скорость, то на Julia лучше писать сетевые сервисы, которые вообще не выгружаются из памяти и делают что-либо по запросу.
56 символов. И читаемость никуда не пропала.
К вопросу о лёгкой читаемости кода на питоне....
Это Ruby, если что...
А это Julia:
И во всех случаях всё прозрачно. Либо читаем последовательно, либо разворачиваем скобки в порядке вложенности.
А что делать с валютными доходами на патенте? Налог на курсовую разницу при любых обменах начисляется на УСН, даже если платёж получен по патенту. Аналогично про процент, начисленный банком по открытым счетам.
docs.juliaplots.org/latest/examples/plotlyjs, plot.ly/julia, randyzwitch.com/ECharts.jl/box
У графиков Plotly будут скроллеры, зум и пр. Также DataFrame при выводе в Notebook отображается со скроллерами. Но только первые и последние строки.
На счет статьи по интерактивному интерфейсу, до нового года взяться не готов. У меня по плану в этом году — генераторы статических отчетов и веб-сервисы. Думаю, нам надо заводить клуб джулиистов и распределять интересные темы по авторам :)
Откровенно говоря, пошаговый отладчик — это вопрос привычки. Отладочная печать типа "@show" и "@debug" доступна в любом случае. А если разрабатываете в Atom/Juno, то есть возможность запустить выделенный фрагмент кода. Когда разрабатываете плоский скрипт, где используется минимум вложенных функций, то проблем нет вообще. Просто выделяете кусок кода и запускаете. Или вбиваете код в REPL, который находится тут же в среде разработки. Сессия со всеми переменными сохраняется до тех пор, пока её явно не перезапустите. То есть работает всё очень быстро. Плюс Juno отображает все выставленные переменные. Сложнее, когда надо отлаживать модули с большим количеством функций. Но и тут, вопрос лишь в стиле написания кода и его адаптации под отладку без пошагового отладчика. Например та самая рекомендация, что функции должны быть короткими. А их запуск в любом случае будет прописан из юнит-теста (в норме, все модули обязаны их иметь), который можно запускать из Juno.
Как следствие, доходы, которые похожи на заработную плату, не будут вызывать вопросы у налоговой. И я не знаю случаев, чтобы кому-то наложили штраф именно за получение зарплаты на иностранный счёт, да и как его потом взять с иностранного же банка.
Также формально нигде не сказано, что лицо, которое работает на иностранную компанию, не имеет права делать это с территории РФ. Налоговая не проверяет сроки пребывания за границей, поскольку не связана с миграционной службой. Однако, если доходы есть, а за границей не был, то это может вызвать вопросы. Если же за границей находился, то доказать, что там не работал, уже вряд ли кто-то сможет.
Соответствеено, каким образом налоговая сможет наложить штраф на зарплату, полученную на иностранный счёт (разрешенный тип операции), и как в суде она сможет мотивировать, что это не зарплата? И зачем вообще налоговой ввязываться в это гиблое дело, если можно просто получить 13%? Заметьте, я не рассматриваю неуплату налога. Это уже другая статья, не имеющая отношения к валютному контролю.
Касаемо сроков пребывания за границей, то расчёт очень прост. Зп программиста $150-200к в год, хотя и не является средней, однако реалистична. Соответственно, если находился за границей месяц, то сумма зп по декларации за год 20-40 тыс. вряд ли вызовет у кого-то вопросы. А если и вызовет, то, опять же, доказать обратное в суде налоговая не сможет. Вопрос чисто порядка сумм.
Но в любом случае, ИП обходится дешевле, чем уплата налогов с иностранных счетов. Кроме того, открытие иностранных счетов, сама по себе, не самая простая задача.
«Мужик в прошлом году» получил штраф при переводах между банками РФ. А тут мы обсуждаем получение заработной платы на себя (первый пункт из той самой 12-й статьи) на личные иностранные счета от иностранных компаний. И это не тот случай нарушения валютного законодательства, когда кто-то хочет получить на валютный счёт физ. лица банка РФ некие валютные переводы от иностранных компаний.
Иностранные банки находятся вне РФ и заморозить что-либо в них по требованию ФНС невозможно. Я согласен с тем, что вопросы возникнуть могут, но, почти уверен, что если суммы более-менее соответствющие заработной плате, претензий у налоговой не будет. Единственное что могут пытаться оспорить — это то, что деньги получены не как заработная плата. Но зачем им это, если Вы добровольно пришли с декларацией доходов.
Дойчебанк на его родине, например, даже счёт без регистрации по месту жительства не откроет. А для того, чтобы её получить, либо придётся селиться в мелком городе, где отсутствует очередь в соответствующее ведомство, либо будете месяц-другой ждать. Потом надо уведомить при отъезде, чтобы через год проблем не было. Да и справки в банк, всё равно придётся приносить. Иначе любые поступления из не задекларированных источников будут заблокированы.
В США без номера социального страхования большинство банков с Вами даже разговаривать не станет. А его, без постоянной работы и визы с разрешением на работу, никто не выдаст.
В целом, везде есть банки, которые согласятся открыть счёт иностранцу без регистрации. Но надежность сохранения денег под вопросом.
Деньги получать чемоданами? Иначе будете платить по местному законодательству. И это сильно больше 13% с иностранных счетов физ. лица. И сильно больше, чем у ИП…
Причём самое главное — деньги могут оставаться в том банке, куда были начислены. Переводить в РФ их не требуется.
Недостаток тут только один. 13% в любом случае. Плюс проценты на перевод к нам и потери на конвертации в рубли, если они нужны. В случае ИП, если это не Москва, налог может быть меньше 1% (по патенту).
По-моему Julia уже достигла зрелости. Именно потому, для задач ML и обработки данных мы решили её использовать. Пару лет назад, вероятно, я бы согласился с python, но сейчас смысла его использования уже нет. Да и примеров уже достаточно. Хотя, в большинстве случаев, их надо искать. Иногда, чтобы понять, как сделать что-то для себя, надо смотреть код библиотек. Но тут — лишь вопрос программистской квалификации и способности быстро понять как оно должно работать. В целом, Julia не является каким-то принципиально новым языком программирования. Это просто переосмысление существующих моделей. Потому начать программировать на ней довольно просто.
В DevOps, не знаю где использовать… Но если есть задачи типа конвертировать какие-либо json, csv, прочие данные в другой формат, откуда-то прочитать, что-то куда-то загрузить, то она вполне может пригодиться. По крайней мере подобные скриптики мы тоже пытаемся делать.
Сейчас уже большинство популярных библиотек перенесли на 1.0. К слову, в Julia очень удобно проверять библиотеки при помощи встроенных тестов. Когда устанавливаете новый пакет, надо всего лишь набрать команду
test ИмяПакета. Если всё в порядке, то можно использовать.Касаемо графиков. Я использую Plots / GR. Каких-либо проблем сейчас не замечаю. Из прочих бакендов, см. http://docs.juliaplots.org/latest/examples/plotlyjs/ — интерактивные диаграммы для jupyter notebook. Из известных мне проблем, в plotlyjs поломаны полярные координаты. В остальном, работает.
И относительно того, как рисовать, Yermack написал серию статей, где, как раз, акцент на графику. Собственно, см. хаб https://habr.com/hub/julia/