Опубликован релиз языка программирования Julia 1.5, сочетающего такие качества как высокая производительность, поддержка динамической типизации и встроенные средства для параллельного программирования. Синтаксис Julia близок к MATLAB с заимствованием некоторых элементов из Ruby и Lisp. Метод манипуляции строками напоминает Perl. Код проекта распространяется под лицензией MIT...Подробнее: https://www.opennet.me/opennews/art.shtml?num=53481
> Динамическая типизация: язык не требует явного определения типов для переменных по аналогии со скриптовыми языками программирования.Так уже определитесь - динамическая типизация, или type inference. Динамическая типизация и высокая производительность несовместимы.
Там все сразу: базовое динамическое типизирование. Если jit компилятор видит, что переменная/аргумент функции всегда одного типа, он делает специализацию функции. Плюс, можно явно указывать типы. В сочетании с mutiple dispatching (не помню, как точно называется: поиск перегруженной функции по всем аргументам) получаетсямощный инструмент.Если я правильно понимаю, в отличие от многих других языков с JIT, в Julia компилятор скорее "обычный", т.е. хотя он и запускается just in time, но больше опирается на имеюшиеся описания типов (как в классических компилируемых языках программирования) с частичным inferring типов (как в ML языках), чем на рантайм-статистику.
Кто-нибудь может мне объяснить, зачем придумывают новые ЯП? Неужели не придумали всё что нужно? Как это происходит, просыпается с утра а напишу ка я новыя ЯП. Или ка это бывает?
Потому что находят фатальные недостатки в других языках программирования. Галактика в опасности, нужно срочно спасать.
Вообще для написания новго ЯП надо быть шизофреником.
Как же здорово, что есть такие "шизофреники", из-за которых нам не нужно тратить время на написание программ в байт-коде.
П.С. Шизофреники обычно задают крайне тупые вопросы в стиле "а зачем писать новые япы?"(академический интерес, новая архитектура, новые задачи и еще десятки возможных причин для написания нового япа).
>зачем придумывают новые ЯП?Julia, так-то, не очень новый.
>Опубликован релиз языка программирования Julia 1.5Ну уж извините, что текст составляет шизофреник а мне не понятно.
Опубликовать и release (выпускать) это масло масленное.
>1.5
>текст составляет шизофреник а мне не понятно.Сейчас бы не видеть разницы между публикацией версии и релизом. Проблема не в тексте, проблема в твоей голове.
>Сейчас бы не видеть разницы между публикацией версии и релизом.Выпуск поставки.
У меня нет проблем. Проблема в твоём воинствующем невежестве.
> Опубликовать и release (выпускать) это масло масленное.Ты хотя бы гуглотранслейт бы заглянул, прежде чем кичиться своим знанием английского (hint: в английском глагол может превратиться в существительное без каких-либо видимых изменений привнесённых словообразованием, глагол от существительного отличать предлагается по контексту использования). Гуглотранслейт промеж прочих вариантов перевода слова release предлагает такие как "версия", "редакция", "сообщение для печати".
Но, чтобы ты мог оценить всю глубину своих заблуждений, я замечу, что в новости использовано не слово "release", а слово "релиз": это слово и произносится иначе, и в другой популяции распространено, и имеет свой собственный смысл, хотя и пересекающийся со смыслом слова "release".
На кончике иголки умещаютсян не 17, а 15 ангелов.
Ну да, конечно же, в 2009-ом году появился, и уже в старую гвардию попал. Ох уж эти зумерки...
Ну да, 11 лет - это же абсолютно ничтожное количество времени для человека, который живет в среднем аж целые 72 года, всего ничего ведь. А твое начальство, если ты конечно не школьник, знает, что тебе можно платить месячную зарплату раз в 11 лет? Ведь даже этого будет много, для человека, у которого 11 лет словно одно мгновение.
Потому что эволюция. Она во всем и ее не остановить. Придумают новые концепции для решения каких-то задач и решают наболевшие проблемы в текущих языках(в том числе и надуманные типа NIH)
Потому что на развитии существующего денег не срубить.
Это не так. Знаю как минимум несколько комании, которые ведут переговоры с разработчиками
как минимум двух интерпретаторов и готовы оплатить им работы или даже сами разработать решение,
но компании не хотят идти на сделку. Сегмент DSL и разработчик какой-то институт.Так что если язык станет популярным (будет использован в нужном проекте), то инвестиции пойдут.
Вопрос в том как убедить акул ИТ сегмента убедить в том, что вот этот Julia дейсвтитльно стоит
внимания, а не использовать какой-то Java или C#, который как говно пристает к каждому
разработчику в университете.
>> а напишу ка я новыяа напишу ка я новый коммент :) как это обычно бывает.
> Неужели не придумали всё что нужно?Насколько же невежественным нужно быть чтобы допускать хоть малейшую возможность того что может быть придумано "всё".
«Всё, что можно было изобрести, уже изобретено», – сказал в 1899 году сотрудник Патентного ведомства США Чарльз Дуэл.
Язык Наскальный v. 2.0- теперь копьё стачивается на 15% меньше
- произдведены оптимизации при работе с хрупкой породой
- можно рисовать коз
Если брать всю общность "новых языков", то ты скорее прав.Но воь с Julia как-то не очень.
Язык появился, чтобы заполнить нишу open source языка заточенного под математические вычисления с высокой производительностью.
В этой стезе конкурентов было не много:
- GNU Octave, который является скорее средой разработки и пытается быть копией MatLab,
- Python с NumPy/SciPy - язык общего назначения, на который натянули возможность делать что-то еще,
- R - преимущественно для статистики.Все три варианта являются интерпретаторами и/или имеют сильно ограниченный JIT. Octave должен еще символьные вычисления делать, т.к. это делает MatLab, Питон должен оставаться питоном, а R для обработки статистики jit вообще не шибко нужен.
Сам факт, что Julia завоевал серьезную популярность, показывает, что получился уникальным и более удобным/консистентным/производительным, чем конкурирующие инструменты. Иначе бы кто бы стал вкладываться в изучение и использование нового языка?
> Сам факт, что Julia завоевал серьезную популярностьа в чем выражается серьезность этой самой популярности?
В том, что его не боятся использовать на суперкомпьютерах, например. Там время разработки и запуска стоят очень дорого, и раз julia был допущен, значит он доказал своë удобство при разработке прототипа.Вообще, об использовании julia информация просачивается из разных источников. Конечно, Python сейчас более популярен для "науки на скорую руку", но Julia явно откусила свой кусок рынка, и отдавать не намеренна.
я очнь хочу написать свой простенький лисп в качестве хобби, потому что это интересно мне
1. либо ктото в рамках изучения яп yacc ии др. попробовал слепить поделку.
2. либо (мое мнение) , крупным корпорациям не нужны программисты, им нужны контентщики что бы развивать свои платформы. для этого создается ЯП с динамич. типизацией идр. модными штучками. там типа все удобно, сборщик мусора, в интернете вбрасывают страшные истории про отстреленные ноги и яйца. по результату имеем стадо покемонов которые спорят срутся по вопросам какой ЯП моднее, на каком проще написать программу для подтирания клоаки, ибо самому взять бумагу это долго и не безопасно, можно рукав запачкать в дерьме, это будет вообще фиаско. А вот в это же время другие, адекватные ребята, на нормальном ЯП, создают эти современные тенденции, и ноги и голова, все у них на месте.
> Код проекта распространяется под лицензией MIT.Вот если бы код написанный на этом, был бы обязан быть под под лицензией MIT, вот тогда было бы кошерно.
>Кто-нибудь может мне объяснить, зачем придумывают новые ЯП?
>Вот если бы кто-то придумал еще одну GPL, но с другими буковками в названии.Дед, иди проверь голову, у тебя уже деменция походу начинается.
С каких пор GPL накладывает подобные ограничения на результаты работы подпадающего под её действие ПО? На license exception в GCC кивать не надо, там особый случай под названием libgcc.
Как бээсдэшник со стажем яростно дизлайкаю ваш провокационный комментарий.
Если бы он был обязан быть под лицензией MIT, то он был бы уже не под лицензией MIT. И тет, жадная капиталистическая жаба, код выпускался и будет выпускаться под GPL, чтобы ты лососнул, а не использовал его на халяву.
> чтобы ты лососнул, а не использовал его на халяву.То есть несвободный код. Лишает меня свободы пользования
поскажите кто нибудь нубасу, где можно доходчиво почитать про разницу между всеми этими лицензиями
Здесь, на OpenNet, где-то была wiki.
примеры программ написанных на сабже в студию
Я начну кормить, пожалуй.
Видел на какой-то конференции про это:
https://github.com/CliMA
Почему кормить? Мне вот тоже интересно посмотреть, что уже написано и на сколько оно сложно в интерпретации. Скажем код на Rust для меня вообще не читаемый и использовать в следующем небольшом проекте я опасаюсь, а вот например новый Python 3.9 можно попробовать, так как там ничего страшного нет.
Когда-то интересовался, нравился. Но потом засосали Perl, Lisp.. стало не до него :)
Это для тех, кого Fortran засосал, действительно
как это ни странно, но некоторые вещи на фортране быстрее чем на си
> как это ни странно, но некоторые вещи на фортране быстрее чем на
> сиТипа матрицы под углом 90 градусов в памяти расположены и доступ к элементу столбца не загораживает следующий?
У Фортрана по дефолту доступ к аргументам подпрограммы по ссылке *для скорости*, не то что в С дурак (непременно) будет огромные структуры копировать. И Сишный рестрикт Там тоже по дефолту у этих ссылкоподобных параметров, не дай тебе бог пересекающиеся данные передать в субрутину, никто же и не проверит, Фортран всё оптимизирует!
Сишное ABI обязует передавать числа и маленькие структуры через регистры, а большие структуры - через указатель на стек. Насколько именно большие - зависит от конкретного ABI, коих десятки.
Глубоко ж тебя засосало.
>одной из ключевых целей проекта является достижение производительности близкой к программам на языке Си.что только ни делают лишь бы не учить Perl/Raku
Им ктото сказал что это не модно...
> что только ни делают лишь бы не учить Perl/Rakuты собрался заниматься математикой на Perl? ну, удачи
Чистой математикой, наверное, действительно не очень удобно. А вот обрабатывать тонны снятых не пойми где не пойми как экспериментальных данных на Perl, внезапно, удобно.
> Компилятор Julia основан на наработках проекта LLVMУносите - не нужно.
Зря ты так категорично.
Большинство JIT, основанных на LLVM действительно оказались в категории "не нужно" потому, что компиляция занимала значительное время в работе проораммы. Но это потому, что большинство пыталось запихать такой JIT в интерактивный язык: чаще всего в языки web разработки, где нужно сделать как можно больше коротких запросов в условиях "сильно объектоориентированного" програмного кода.LLVM явно не про это. LLVM конечно компилит быстрее, чем GCC, но все равно долго. А обьектноориентированный код с упором на полиморфизм/duck typing вообще мало выигрывает от оптимизаций на уровне машинных кодов, там нужны более высокоуровневые оптимизации.
Но с Julia совсем другая история. Т.к. это язык математических вычислений, программы на нем изначально работают заметное время, и пользователь Julia готов к этому. Потому долгое время компиляции здесь не является напрягаюшим фактором. А т.к. библиотеки и код насышены явнымм определениями типов, и jit, перед тем, как передать код в LLVM, делает усиленный type inferring и другие высокоуровневые оптимизации, LLVM попадает в среду, где он проявляет лучшие свои качества: оптимизировать низкоуровневые вычисления с известными низкоуровневыми типами.
Джулия опирается на линию языков математического программирования, но также многое заимствует из популярных динамических языков, включая Lisp , Perl , Python , Lua и Ruby .
и ВСЁ
И этого оказалось достаточно.
Сейчас Julia в основном про сложную математику, где надо много считать. Численные вещи решались на фортране, какое-нибудь решение PDE было хорошо в матлабе, всё это уже хорошо делает Julia. Она к слову один из 3х языков, которая выбивала петафлопные вычисления на HPC машинах.
Но ещё она хочет залезть в область Data Science/Machine Learning. Там где сейчас Python/R правят баллом. И даже скорее PyTorch/Tensorflow вот тут у Julia есть Gen, с встроенным в язык автодифференцированием так необходимым для градиентов, на которых это всё основывается.
Но кто идёт часто работать в DS после академической области? Правильно математики и физики. И если у них Julia станет стандартом де факто (пока она продвигается сильно только в штатах и особенно в MIT), то потом она же теоретически сможет занять место Python. Думаю у них план такой :)
Сложная (и быстрая) математика, включая "численные вещи", делаются на С.
А совсем уж критичные фрагменты — и вовсе на *asm.
И чем это опровергает утверждение выше?
Зачем их делать на C, если есть Julia?
В том числе и на Си, но существует огромные области, где исторически всё делается на фортране. Работа с матрицами и тензорами (срезы) там сделаны гораздо удобнее, например.
Навье-Стокса, CFD и кучу других вещей с использованием Coarrays, OpenMP, MPI, Blas, PETSC,Lapack и иже с ними библиотеками.
> гораздо удобнееЧем в Си? Откройте исходники SSP/ESSL на Фортране и исходники нормального пакета на Си и убедитесь, что принципиальной разницы нет - основной принцип заключается в одномерном хранении массивов любой размерности. Чем, собственно, и достигается примерно одинаковое быстродействие аналогичных алгоритмов.
Внутри пакета, который жестко заточен на оптимизацию возможно (если честно в исходниках мат пакетов особо не копался). Но я же говорю, что до вызова пакета с данными как-то ещё работает исследователь. И тратить время на просчёт корректности индексов при развёртке своих н-мерных тензоровьто ещё удовольствие. Да и понятность логики и читаемость кода теряется.
А когда я говорил про срезы имел в виду этот пример https://en.m.wikipedia.org/wiki/Array_slicing
Гугл подсказал, что некоторые компиляторы (Sun) и возможно новые стандарты плюсов что-то вводили, но я никогда такого не встречал.
Забавно, как на опеннете любят постоянно кричать про фанбоев раста. При этом в топике про ЯП для математиков, которым небольшой профит от скорости C по сравнению с Julia в 99% случаев как собаке пятая нога для бега, набежали сишники и рассказывают о том что кроме великого и неподражаемого С языки не нужны. Действительно, зачем нужна кувалда когда есть ювелирные молоточки? Зачем все эти глупые люди используют инструменты которые им удобны для решения задач?
> ЯП для математиковА нужен ли вообще этот специальный ЯП для математиков? Математикам удобнее готовый софт юзать в ряде случаев (но не всегда). Mathlab, Octave, Maxima и т.д. - вот что реально будет юзать математик. Попытки создания "ЯП'ов для пользователей" - так себе идея. Один только пистон чего стоит. Julia - это, по сути, ЯП для пользователей. В любом случае что-то нетривиальное придётся делать на том же C++ и функциональных ЯП. Математику выгоднее какой-нибудь OCaml освоить, нежели Julia. На чём там фронтэнд Julia написан? С, C++ и, внезапно - Scheme. Maxima написана на Common Lisp. Функциональные ЯП вполне себе годны как для создания математического софта, так и для вычислений. Непонятно, в какую нишу метит эта Julia. Разве что как замена математическим питоно-библиотекам.
Ну вот, Юля уже есть, осталось для математиков написать свой Mathlab с фракталами и 3D-визуализацией функций. И назвать его Scilab, FreeMat, GNU Octave или Genius. Ой, блин такое уже есть. Осталось только их спарить с Юлькой.П.С. Последним двум упомянутым надо ещё интерфейс немного поправить...
Производительность работы и вычислений большинства названных пакетов уступают Юльке
> Возможность прямого вызова функций из библиотек на языке Си без дополнительных прослоек.Это свойство любого достойного языка программирования. И это же аргумент, почему иные языки программирования, кроме С, не нужны.
>> Возможность прямого вызова функций из библиотек на языке Си без дополнительных прослоек.
> Это свойство любого достойного языка программирования. И это же аргумент, почему иные языки программирования, кроме С, не нужны.Ну бред же пишешь. На TurboPascal легко внедрял модуль EGAVGA в исполняемый файл — отдельная подгрузка кода времени выполнения из модуля для работы с графикой не требовалась.
Из Java получал доступ к динамическим библиотекам, откомпилированным в Delphi. Где тут Си? Что я делал не так?
> TurboPascalОчнись, 92 год (до дележа сфер интересов) давно прошел.
Да, и погугли "На чем написан Delphi". Удивишься.
И Java, кстати, тоже. :))
> Да, и погугли "На чем написан Delphi". Удивишься.Turbo Pascal кроме библиотеки TurboVision написан на Turbo Pascal!
Delphi среда и библиотека VCL написаны на Object Pascal/Delphi Pascal. Библиотека визуальных компонентов (VCL) также используется в C++Builder (в сишной среде очень тормозной компилятор — раз в десять тормознее дельфового на простых проектах).
Для OCX/ActiveX компонентов в среде Delphi есть специальный компилятор для внедрения компонентов в виде "обёрток" этих объектов в саму среду, на палитру компонентов и работы с ними в режиме визуального проектирования в среде дизайнера форм. Также есть "обратный" процесс — любой компонент VCL можно преобразовать в OCX/ActiveX-компонент и использовать уже бинарную библиотеку (в формате файла .OCX или .DLL) в других средах разработки.
Borland JBuilder был написан на C++, но впоследствии к четвёртой версии, кажется, переписан на Java с Look&Feel Metal Swing, а затем перешёл на платформу NetBeans и отвязался от нативного кода вообще.
Правильно я понимаю, что Go недостоин?
Нет, вы видимо просто не знаете что Go даёт возможность не только делать вызовы функций C без всяких прослоек, но даже позволяет писать на С внутри файла с Go кодом:package main
/*
#include <stdio.h>
void hello(void) {
printf("Hello from C function!\n");
}
*/
import "C"func main() {
C.hello()
}$ go run test.go
Hello from C function!
Там одна только беда с интеграцией в Си рантайм это ThreadPool на стороне Golang,
который расхреначивает весь не tread-safe код.
> и генерирует эффективный нативный машинный код для многих целевых платформ;s/эффективный/огромные файлы размером в 10-ки мегабайт даже для Hello World/g
s/нативный машинный код/только при очень сильном желании может быть получится сгенерировать нативный машинный код/g
Да, математики очень страдают от бинарников в 10 мегабайт и не до конца нативного машинного кода. Отправляют их на сервера вычислительных центров с сотнями гигабайт RAM на каждой ноде чтобы крутить расчеты неделями и рыдают просто от того что файл грузился не секунду, а две.
Серьезно, я понимаю, что у ретроградов есть фетиш на С, но люди которые работают предпочитают все-таки использовать удобные инструменты для решения задач которые повышают их продуктивность. Людям все-таки обычно платят за результат а не за фанбойство.
> Людям все-таки обычно платят за результат а
> не за фанбойство.Да причем здесь фанбойство ?
Вы попробуйте скомпилировать что нибудь и поймете о чем речь.
Маркетить язык фичами которыми он не обладает - это как политик, который наобещал и не сделал
А, сорри, я затупил и не понял что это был наезд на их действительно спорный маркетинг компиляции в нативный код. Просто пролистав кучу сообщений вида "кроме C больше ничего не нужно" я подумал что это очередной наезд на то что язык не С. Ты прав а я не прав.
> Ты прав а я не прав.Я правда рад, что здесь есть люди подобные Вам!
Вопрос как всегда не в языке, а в развитии экосистемы. Сколько библиотек реализуют: графику, чтение документов Word/Excel, работу с базами данных, работу с сетью, работу с принтером, работу с GUI, работу с PDF и т.д.Просто обычно нужно решить вполне прикладные задачи, а для математики и прочей автоматизации уже столько дерьма написано, что даже лень говорить ...
> Сколько библиотек реализуют: ....Достаточно одной хорошей библиотеки. Исследовать россыпь разной степени готовности - мало кого заинтересует....
У Julia с перечисленными выше задачами уже всё в порядке.