caxapa.ru :: [Julia] is a high-level, high-performance dynamic programming language for numerical computing -> GitHub --> Вроде бы у нас не было, а зря.

Evgeny_CD, Архитектор (27.11.2017 23:29, просмотров: 31605)

[Julia] is a high-level, high-performance dynamic programming language for numerical computing -> GitHub --> Вроде бы у нас не было, а зря. https://github.com/JuliaLang/julia
https://julialang.org/
Натолкнулся совершенно случайно, выпал в осадок. * Windows 7+, Linux 2.6.18+, macOS 10.8+ * В стандартный комплект входит JIT-компилятор на основе LLVM. Бенчмарки впечатляют * Call Python functions: use the PyCall package * Call C functions directly: no wrappers or special APIs * ...в языке была сразу реализована поддержка облаков и параллельного программирования как замена механизму MPI. В языке была изначально реализована модель построения больших параллельных приложений, основанная на глобальном распределенном адресном пространстве. Такая модель подразумевает возможность производить операции (в том числе и их передачу между машинами) со ссылкой на объект, расположенный на другой машине, также участвующей в вычислениях. Этот механизм позволяет отслеживать какие вычисления на каких системах выполняются, а также подключать к производимым вычислениям новые машины * ориентация GUI сразу на прикладной уровень, гарантированно совместимый со всем. В части GUI все заточено под красивую визуализацию данных. * в целом понравилась [на первый взгляд] простота и сбалансированность. Языковая базовая часть четко отделена от надстроек. * нехилая экосистема - от различных пакетов до всяческих расширений https://julialang.org/ecosystems/ * Verilog for Julia https://github.com …etary-robot/Verilog.jl Для embedded целей видится как универсальный инструментальный язык. Суть идеи * моделирование и интеграция * прямое управление С кодом - например, синтетическим портом RTOS и приложением под ним * быстрое создание GUI для управления всем этим. В чем-то напоминает Tcl по замыслу, но "современно выглядящих" тулзов сильно больше Почему мы создали Джулию, новый ЯП для технических вычислений https://habrahabr.ru/post/138577/ Почему я делаю ставку на Julia https://habrahabr.ru/post/210298/ Википедия https://ru.wikiped …0%B0%D0%BD%D0%B8%D1%8F) https://en.wikiped …_(programming_language) В качестве ГУЯ использует Jupyter Project Jupyter is a non-profit, open-source project, born out of the IPython Project in 2014 as it evolved to support interactive data science and scientific computing across all programming languages. http://jupyter.org/index.html The Jupyter Notebook The Jupyter Notebook is an open-source web application that allows you to create and share documents that contain live code, equations, visualizations and narrative text. Uses include: data cleaning and transformation, numerical simulation, statistical modeling, data visualization, machine learning, and much more.

Ответить

- Кстати, Jupyter тесно связан с IPython ->. Это часть IPython, языконезависимая, которую вынесли в отдельный модуль в IPython 4.0 (сейчас актуален IPython 6.1) - Evgeny_CD(27.12.2017 22:36, ссылка)
- Что интересно, Julia имеет биндинги с Tk (ну и там целиком встроенный Tcl имеется...) - fk0(29.11.2017 00:23, ссылка)
- Julia Micro-Benchmarks -> Сильно интересно! Evgeny_CD(347 знак., 28.11.2017 11:50, ссылка)
  - Быстрее С может быть только ассемблер. Напши свой _write(), с буферизацией. Дупкин(82 знак., 28.12.2017 22:03, )
    - Нет, быстрее Цэ - только DMA и аппаратные ускорители. lloyd(110 знак., 28.12.2017 22:06)
      - Есть пару моментов, вроде разворачивания циклов(с переменным числом итераций), которые легко реализуются на ассемблере, а на C никак. Дупкин(60 знак., 28.12.2017 22:19, )
        
        #pragma UNROLL и nassert() есть у некоторых вендоров (TI) - lloyd(28.12.2017 22:36)
        
        Поправте если ошибаюсь, но #pragma UNROLL не работает, если число итераций не известно на момент сборки. - Дупкин(28.12.2017 22:53, )
- Сильно МатЛабово. Точки с запятой из С++ убрали - считают, что новый язык сочинили :). А если серьезно, то эффективность кода и удобство в языка находятся на разных полюсах, а потому здесь возможен только компромисс. Причем компромиссное решение Ксения(2445 знак., 28.11.2017 11:33 - 11:38)
  - > Скажем, действительно очень удобно, когда функции возвращают не одно единственное значение, а способны выдать список того же рода, что и список своих параметров. lloyd(28 знак., 28.11.2017 15:17)
    - Иногда 1..2 goto в main{} более читабельны, нежели все остальное. А функция вполне может возвращать указатель на структуру (список своих параметров). _basile(45 знак., 28.11.2017 19:57, )
      - >возвращать указатель на структуру lloyd(368 знак., 28.11.2017 20:47)
        
        Да, я так и не делаю. _basile(309 знак., 28.11.2017 22:29, )
    - Это не совсем то. Я-то имела в виду запись типа матлабовской: [U,D,V]=svd(M); // сингулярное разложение матрицы на левые U и правые V соб.вектора и диагональный вектор D. Причем, любой из этих выходных параметров может быть опущен (но запятые Ксения(12 знак., 28.11.2017 16:14)
      - Ксюх, ну, ты дала... Один хрен из великих так конкретно и сказал:"Все гениальное - это просто". _basile(61 знак., 28.11.2017 22:47, )
      - tuple - это явный признак говнокода (как раньше таковым считали goto) lloyd(173 знак., 28.11.2017 17:28)
        
        Аффтары цэ++ - это коллективный взбесившийся принтер :-) - SciFi(28.11.2017 17:30)
  - ИМХО "свободная типизация" переменных - зло даже без оглядки на размер кода. Ибо источник трудноуловимыых ошибок типа сравнения строки с числом и т.п. - Сидоргек(28.11.2017 12:30)
    - Мою дочь в школе учили программированию как раз на питоне. Аргумент: типы данных сложны, школьники их не понимают, поэтому нужно учить языку "без типов". Первая программа: input a input b print a+b. Дочь её запускает, вводит 2 2, ожидает ответ 4, йцукен(109 знак., 28.11.2017 12:57)
      - Дело не в динамической типизации, а в перегрузке смысла оператора "+" для чисел и строк. В Tcl такой проблемы нет. Строки складываются или числа _разными_ функциями. А строка в число превратится сама, если конечно сможет в конкретном случае (2 + fk0(28 знак., 28.11.2017 23:33)
    - Зависит от области применения. Для инструментальных языков, где программа может выполниться всего несколько раз - вполне допустимо, если повышает скорости написания программы. Evgeny_CD(96 знак., 28.11.2017 12:49)
      - Отсутствие типизации плодит ошибки в больших программах. А большую программу не запустишь и тестами как скрипт на все 100 процентов так просто не покроешь. Нет проверки корректности в момент компиляции. - fk0(28.11.2017 23:35)
        
        В идеале должна быть настраиваемая типизация. Если ты пишет "малую программу", которую ты будешь сопровождать сам, и понимаешь все риски такого подхода - ставишь ключик и вперед. Evgeny_CD(160 знак., 28.11.2017 23:42)
        
        Для этого просто существуют разные языки! Смотри вторую ссылку: fk0(1090 знак., 28.11.2017 23:57 - 29.11.2017 00:05, ссылка, картинка)
        
        Спасибо! - Evgeny_CD(29.11.2017 00:10)
  - Большое спасибо! Комментарии. Evgeny_CD(1632 знак., 28.11.2017 12:21, ссылка, ссылка)
    - А если "не уступает С кратно", то там не свободная типизация, а ... паллиатив :). Рассмотрим пример: Ксения(1432 знак., 28.11.2017 12:59 - 13:06)
      - Спасибо! Классно пояснили! - Evgeny_CD(28.11.2017 13:01)
        
        Я вообще-то свой метод открыла :), как обойти явную типизацию, хотя и не уверена, что кто-то не открыл его раньше: Ксения(2501 знак., 28.11.2017 14:49 - 14:53)
        
        Спасибо! Получается интересный "транзитивный" подход: операция -> адаптер данных -> данные. Но тогда, возможно, удастся сделать универсальный шаблон класса. Evgeny_CD(451 знак., 28.11.2017 23:48)
        
        В многих языках есть утиная типизация, а у некоторых интерфейсы. Не обязательно жесткое наследование. - fk0(28.11.2017 23:37)
        
        Утиная типизация - это оно? -> --> - Evgeny_CD(28.11.2017 23:57, ссылка, ссылка)
        
        почему-то кажется, что такой тип должен быть классом. и на C# - Vit(28.11.2017 21:51)
        
        Красиво :) - Скрипач(28.11.2017 19:33)
- Есть такой Eric S. Raymond. Авторитет в узких кругах, видимо. Рассуждает о заменах языку Си. Упоминает Go и Rust. Говорит, когда сборка мусора перестанет тормозить, будет круто. - SciFi(28.11.2017 00:56, ссылка, ссылка)
- Не понял, они там опять фортран изобретают? - blackprapor(28.11.2017 00:42)
  - типа того. Страдальцы :) - scorpion(28.11.2017 01:01)
- Важный момент по поводу параллельного программирования. С учетом изначальной кросс-платформенности Julia возможно это даст возможность легко строить гетерогенные среды разработки. Evgeny_CD(389 знак., 28.11.2017 00:14, ссылка)
- Фишка в том, что оно на LLVM основано. И позволяет собирать написанный под него код вместе со сторонним С (С++?) кодом, как я понял. Без всяких прокладок или с их минимумом. Evgeny_CD(595 знак., 27.11.2017 23:41)

Средства и методы разработки