На предстоящей (http://llvm.org/devmtg/2012-04-12/) европейской конференции проекта LLVM (http://llvm.org/) в Лондоне будет (http://permalink.gmane.org/gmane.comp.compilers.llvm.devel/4... официально представлен новый язык программирования Julia (http://julialang.org/), использующий JIT-компилятор на базе наработок проекта LLVM (http://llvm.org/). Julia является динамическим языком высокого уровня с открытым исходным кодом (https://github.com/JuliaLang/julia) (лицензия MIT), нацеленный прежде всего на техническое программирование в статистико-математических областях, с областью применения аналогичной таким известным решениям, как Matlab, язык R и связка из Python и NumPy.
Julia мультипарадигменный язык, который может комбинировать разные стили программирования, такие как императивный, объектно-ориентированный и функциональный. Синтаксис Julia очень близок к синтаксису MATLAB. По мнению создателей этого языка, к его достоинствам также следует отнести множество заимствований из синтаксиса Ruby и Lisp, удобная работа со строками в стиле Perl, кроме того обеспечена очень гибкая встроенная поддержка Hadoop (http://hadoop.apache.org/). Уже идет работа по реализации полиморфных функций, поддержки задействования GPU для ускорения вычислений, автовектаризации и прочего.
Отдельно следует подчеркнуть, что язык Julia изначально спроектирован с учетом поддержки параллельного программирования (http://julialang.org/manual/parallel-computing/) (например, реализованы так называемые Coroutines (http://en.wikipedia.org/wiki/Coroutine)), поэтому эта среда очень хорошо подходит для таких актуальных сегодня областей, как виртуализация и облачные вычисления, практическая работа со стороны разработчиков языка по экспериментированию в этих областях уже начата.Если же попытаться выделить основные новшества и отличия этого языка от ему подобных, то в качестве первого важного отличия Julia следует отметить его сильный акцент на производительности, больше сопоставимой по своим характеристикам с языком С, а также полная открытость технологии для сообщества.
<center><img src="http://www.opennet.me/opennews/pics_base/0_1331397508.png" style="border-style: solid; border-color: #000000; border-width: 1px;" title="" border=0></center>Ещё одна важная особенность Julia - язык исповедует (http://julialang.org/manual/calling-c-and-fortran-code/) "безшаблонную" философию: внешние функции могут вызываться из Julia напрямую без какого-либо "кода для сопряжения" параметров вызова и библиотеки, и это можно делать не только из скомпилированного кода программы на Julia, но даже из интерактивной командной строки. Единственное ограничение для такого подхода - библиотеки с вызываемыми функциями должны быть представлены в виде "
"разделяемой библиотеки". Впрочем, большинство библиотек для C или Fortran'a распространяются как раз именно в таком виде. Машинные инструкции, которые генерирует JIT-компилятор (http://en.wikipedia.org/wiki/Just-in-time_compilation) Julia в этом вызове - полностью аналогичны тому коду, который сгенерировал бы C-компилятор, поэтому накладные расходы от вызова внешней функции из Julia здесь почти такие же, как и в C. В этой области возможно ещё множество оптимизаций, которые будут реализованы в этом языке в ближайшем будущем.Другие интересные особенности этого нового динамического языка:
- Ядро языка очень невелико, его стандартная библиотека включает минимальный набор примитивных операций, такие как например арифметические операции, т.е. гибкая масштабируемость языка;
- Богатый язык типов для описания и конструирования объектов;
- Возможность определять поведение функции при передачи разного количества аргументов через multiple dispatch (http://en.wikipedia.org/wiki/Multiple_dispatch);
- Автоматическая генерация максимально эффективного кода для разных типов аргументов и переменных;
- Полная поддержка Unicode;
- Мощные шелл-подобные функции для запуска и управления внешними программами и процессами.URL: http://permalink.gmane.org/gmane.comp.compilers.llvm.devel/4...
Новость: http://www.opennet.me/opennews/art.shtml?num=33315
это эпидемия что-ли такая "новый язык программирования"??
Да я вот тоже не понимаю, вместо того чтобы взять существующии и расширить люди пилят новый. Думаю каждый случай надо рассматривать отдельно, однако, #$!#$T@#!!!
ну куда еще расширять то? взять те же плюсы? не расширять надо а приводить в порядок, да вот только с учетом совместимости, привычек, духа, организации и т.п, это мало реально, проще новый сделать.
> ну куда еще расширять то? взять те же плюсы? не расширять надо
> а приводить в порядок, да вот только с учетом совместимости, привычек,
> духа, организации и т.п, это мало реально, проще новый сделать.Привели плюсы в порядок, получился D, красивый, простой и мощный. Много им народу пользуется? Нет же, жрут всё те же кактусы, гуи пишут на плюсах, а то и на сях.
Пропаганда нужна и сообщество типа RoRовского.
Для того, чтобы сейчас сколь угодно прекрасный и правильный язык вдруг стал популярнее плюсов, кто-то должен бесплатно потратить несколько сотен человеко-лет на написание к нему библиотек в объеме, хоть сколько-нибудь сравнимом с плюсовыми.
Без критической массы существующего кода никакие теоретически великолепные языки никому нахрен не нужны.
> Для того, чтобы сейчас сколь угодно прекрасный и правильный язык вдруг стал популярнее плюсов, кто-то должен бесплатно потратить несколько сотен человеко-лет на написание к нему библиотек в объеме, хоть сколько-нибудь сравнимом с плюсовыми.Фортран — прекрасный и правильный язык, библиотек для которого на несколько порядков больше, чем для плюсов. И как, сильно фортран популярен?
В определенных кругах - там где управляют ракетами и прочими алгоритмоемкими вещами - там фортран очень, очень популярен. А вот гуев к нему, действительно, нет.
не совсем. его применяют в основном там, где считают, что фортран - быстрее. очень часто не зная о том, когда фортран быстрее.
Не-а. Фортран - это огромное количество библиотек с реализациями математических методов. Очень хорошо отлаженных. Какой бы из численных методов не взять, он непременно будет реализован на фортране. И реализован без ошибок. Стало быть, если надо рассчитать траекторию спутника...
вы никогда не видели обработку матриц от "спецов"? когда матрицы обрабатываются сугубо как в сях, а не как это должно делаться в фортране. там еще других приколов - море, типа "профайлер? а что это?"
Ну допустим, у фортрана обилие прекрасных библиотек. Но он вроде бы вполне нормально компонуется с модулями на других языках - что мешает использовать фортрановские либы с основной программой, скажем, на С? Нафига писать новое на фортране, если его изучают и поддерживают, по существу, ради обратной совместимости?
В Европе очень популярен язык.
Говорю про авиастроение.
Много мейнфреймов работают как раз с фортраном и MPI.
При получении т.з. - язык фортран или джава с импортом-эскпортом фортран байндиногом.
> - там фортран очень, очень популярен. А вот гуев к нему, действительно, нет.The gtk-fortran project aims to offer scientists programming in Fortran a cross-platform library to build Graphical User Interfaces (GUI). Gtk-fortran is a partial GTK+ / Fortran binding 100% written in Fortran, thanks to the ISO_C_BINDING module for interoperability between C and Fortran, which is a part of the Fortran 2003 standard. GTK+ is a free software cross-platform graphical library available for Linux, Unix, Windows and Mac OS X.
> Фортран — прекрасный и правильный язык, библиотек для которого на несколько порядков
> больше, чем для плюсов. И как, сильно фортран популярен?На несколько порядков - явное преувеличение.
Нет, явное преувеличение - "больше". На несколько порядков меньше - ближе к истине.
Просто ни один из существующих языков не является абсолютно оптимальным; у каждого свои недостатки и своя область применения. Вот и пытаются создавать языки предназначенные для конкретных применений.
Этих причин явно недостаточно, т.к. проблема в этом случае решалась бы простым расширением одного языка (ассемблера).
Чушь. Вы на ассемблере писали?
Не чушь. Писал и если надо напишу. Вдумайся что сказано было. Про HiAsm слышал? А теперь развивай мысль и слови баттхерт.
Услышал. Увидел _ещё один_ графический яп.
Чушь. Скорость написания кода и, особенно, его отладки на ассемблере в десятки раз медленнее, чем на любом вменяемом языке.
> Чушь. Скорость написания кода и, особенно, его отладки на ассемблере в десятки
> раз медленнее, чем на любом вменяемом языке.фигня. на самом деле на ассемблере достаточно написать Forth, на нём — Scheme, а дальше уже на Scheme писать всё, что надо.
Форт... Нас учили этому чудищу в университете. Было прикольно и страшно...
> Форт... Нас учили этому чудищу в университете. Было прикольно и страшно...да ну, форт простой как обухом по черепу. проще ассемблера даже, пожалуй.
Он очень прост, особенно если раньше программировал на калькуляторе. Но от этого он не становится менее прикольным и страшным.
>> Чушь. Скорость написания кода и, особенно, его отладки на ассемблере в десятки
>> раз медленнее, чем на любом вменяемом языке.
> фигня. на самом деле на ассемблере достаточно написать Forth, на нём —
> Scheme, а дальше уже на Scheme писать всё, что надо.А потом на Scheme написать Яву? :) И дальше писать все, что надо уже на ней? Это гарантия скорости, ведь в самом начале был асм :)
> Не чушь. Писал и если надо напишу. Вдумайся что сказано было. Про
> HiAsm слышал? А теперь развивай мысль и слови баттхерт.А причем тут HiASM? Он к ассемблеру, как языку программирования, имеет весьма условное отношение.
Расширение приводит к каше, усложняет реализацию, понимание, специализированный инструмент лучше универсального, да и к тому же многие вещи в основе так или иначе, расширяй не расширяй а икаться будут, в сях например, минимальность ядра и строгая типизация к чему привели? - к куче разрозненных реализаций одного и того же - яркий пример юникодные строки, или скажем костыли для обхода типизации вроде всяких шаблонов и дженериков... расширение расширением а без коренного пересмотра основы не обойтись
> у каждого свои недостаткиПри том как правило - фатальные, и называются NIH :)
Зачем так много языков программирования?? Я один еле еле осилил, и тоне до конца! Каждый день новый язык программирования, сколько же можно елы-палы, это же какое-то помешательство!!!
Успокойтесь, любезный, и пилите дальше Ваш бейсик. :)
s/пилите/используйте/
Это поиск идеала и заполнение ниш. Думаю в ближайшее время будет много языков которые постараются заменить Java и C#,
> Это поиск идеала и заполнение ниш. Думаю в ближайшее время будет много
> языков которые постараются заменить Java и C#,чтобы избавиться от зависимости от Oracle и Microsoft
Тут не языки а либы писать надо.
Для либ уже есть python
а также перл и руби
> чтобы избавиться от зависимости от Oracle и MicrosoftИ от тормозной и жрущей память виртуальной машины.
Языков то полно, а вот чтобы сразу писать - с гуями и вебмордами, с подключением баз и работой с документами odt/M$ - кот наплакал. Куда ни ткнись - всюду только концепции и описания синтаксиса.
А если из оставшихся отбросить те, у которых пригодные к использованию библиотеки принадлежат какой-нибудь корпорации - выбора не остается вообще.
А чем Вам не нравятся Qt и OpenJDK?
Не достаточно элитны.
Почему - не нравятся?
Просто существует нехилая вероятность, что некую программу, развитие которой для вас критично, внезапно надо будет сильно переписать. И вы на эту вероятность повлиять никак не можете. А ОДИН человек может...
Это вы о чем?
> Синтаксис Julia очень близок к синтаксису MATLAB.Это пугает.
> следует отметить его сильный акцент на производительности
О... Сравнение с Matlab/Octave действительно внушаитЪ. Смотрим. Ага! Они радостно запилили фиббоначи с использованием рекурсии. Двойка "тестерам" за знание матчасти. Занавес.
> полная открытость технологии для сообщества
Закрытые Octave, R и NumPy - ну такие закрытые. Бот что-ли новость писал?
> > Синтаксис Julia очень близок к синтаксису MATLAB.
> Это пугает.Ну почему же. Синтаксис матлаба не так плох. Даже не смотря на использование круглых скобок для обращения к элементам массива. Или на использование специальных переменных для возврата значения функции вместо человеческого оператора return. Или на контринтуитивные списки аргументов в стандартных функциях. Или на отдельные ключевые слова endfor/endif/endfunction и т.д. для разных блоков. Вот, к примеру, поэлементные операторы в матлабе очень удобны.
Синтаксис, по существу, один из наименее важных факторов, несмотря на притягательность этого вопроса для холиваров. Вон, в лиспе вообще с этим не заморачивались )
> Вон, в лиспе вообще с этим не заморачивались )потому что там дали инструменты для создания любого удобного синтаксиса. притом намного более мощные, чем просто препроцессор. в общем-то, чит, но крутой.
Это синтаксис более высокого уровня - конструкции, а базовый синтаксис (типа скобок) в лиспе обычно не меняют, хотя тоже можно. А срачи возникают обычно именно вокруг полной ерунды типа формы скобок или, например, написания оператора присваивания = vs :=, что, по большому счету, дело привычки и ни разу не влияет мощность языка
> оператора присваивания = vs :=, что, по большому счету, дело привычки и ни разу не влияет мощность языкану тут ведь такое дело, любому изучавшему арифметику (не ну я понимаю что программисты к ним не относятся) известно что = значит равно т.е. это немного как если бы заменили 3 на 9 и наоборот, привыкнуть то можно конечно...
кстати в языке вообще не обязательно иметь только 1 оператор присваивания, вот например в этом довольно известном языке их 5 штук
Assignment Operators
Description - Assign a value to a name.
Usage
x <- value
x <<- value
value -> x
value ->> x
x = valueчто до скобочек то скажем разделение () и [] позволяет сразу отличить вызов функции от индексирования массива, ну и т.д.
не ну я опять же понимаю что логичность обозначений и читаемость кода никак не влияют на мощность языка, дело привычки же, китайцы вон пишут иероглифами и довольны, с клавиатуры правда вводить неудобно, но дело привычки же
> Ну почему же. Синтаксис матлаба не так плох.Для 80-х - да. А сегодня там "не плохо" - только все что связано с линейной алгеброй.
> Или на отдельные ключевые слова endfor/endif/endfunction и т.д. для разных блоков.
Это вы matlab с octave перепутали. Там ублюдочные end переделали в не менее ублюдочные end<shit>.
> фиббоначи
> ДвойкаАй-яй-яй-яй-яй.
Имеются огромные сомнения насчет того что и как они сравнивали с NumPy. В среднем на порядок быстрее говорите? И яваскрипт тоже также быстрее NumPy на порядок? То есть в разы быстрее чем С/С++. Ага, щас.
https://github.com/JuliaLang/julia/blob/master/test/perf/per...я так и думал - от NumPy там только фактически import numpy да создание массивов. вот примерчик:
def mandel(z):
n = 0
c = z
for n in xrange(0,79):
if abs(z) > 2:
n -= 1
break
z = z**2 + c
return n + 1def mandelperf():
r1 = numpy.arange(-2.0, 0.5, 0.1)
r2 = numpy.arange(-1.0, 1.0, 0.1)
M = numpy.zeros((len(r1)*len(r2)))
count = 0
for r in r1:
for i in r2:
M[count] = mandel(complex(r,i))
count += 1
return M
Единственная тестовая функция, действительно задействующая NumPy для вычислений:def randmatmul(n):
A = matrix(numpy.random.rand(n,n))
B = matrix(numpy.random.rand(n,n))
return A*Bсмотрим в таблицу - так и есть, для этого теста разница практически незаметная.
То есть сравнивали с python а не numpy. И не факт, что корректно.
Да тесты булшит же откровенный. С этого момента весь интерес пропадает к языку.
> Имеются огромные сомнения насчет того что и как они сравнивали с NumPy.
> В среднем на порядок быстрее говорите? И яваскрипт тоже также быстрее
> NumPy на порядок? То есть в разы быстрее чем С/С++. Ага,
> щас.Исходники же есть. Возьмите и проверьте.
numpy вычисляет со скоростью близкой к предельной - для заданного алгоритма и железа, поэтому обогнать его даже в 2 раза практически нереально. Потому что внутри у него не питон, а самый что ни на есть с/с++. А тут нам внезапно про десятки раз быстрее втуляют. Чистый питон ради бога пусть обгоняют - но и писать надо при этом про питон, а не numpy, это как бы 2 очень большие разницы (на порядки) по скорострельности. при чем тут сырцы?
> numpy вычисляет со скоростью близкой к предельной - для заданного алгоритма и железа, поэтому обогнать его даже в 2 раза практически нереально. Потому что внутри у него не питон, а самый что ни на есть с/с++.NumPy это вообще то не язык, а библиотека для Питона, о чем легко узнать заглянув на сайт проекта
http://numpy.scipy.org/
NumPy is the fundamental package for scientific computing with Python.
в следующий раз, пожалуйста, используйте ник К.О.
> в следующий раз, пожалуйста, используйте ник К.О.А, то есть здесь всем кроме меня понятно как можно сравнивать язык программирования с библиотекой для языка программирования?
> что внутри у него не питон, а самый что ни на есть с/с++.Угу. Остается вопрос зачем пользоваться тормознутым питоном. Наверное чтобы при нужде дописать чего-то чего нет в numpy словить тормоза и героически бороться с ними :)
>> что внутри у него не питон, а самый что ни на есть с/с++.
> Угу. Остается вопрос зачем пользоваться тормознутым питоном. Наверное чтобы при нужде дописать
> чего-то чего нет в numpy словить тормоза и героически бороться с
> ними :)Может потому что это удобно?)
> язык Julia изначально спроектирован с учетом поддержки параллельного программирования (например, реализованы так называемые Coroutines)При чем тут coroutines к параллельному программированию? Они же не могут выполняться одновременно. Это не параллельность получается, а банальная многозадачность, при чем невытесняющая.
> При чем тут coroutines к параллельному программированию? Они же не могут выполняться
> одновременно. Это не параллельность получается, а банальная многозадачность, при чем невытесняющая.http://ru.wikipedia.org/wiki/Сопрограмма
По приведенной ссылке нет ничего, опровергающего мои утверждения. Что сказать-то хотели?
(я другой аноним)Верно, не параллельность по отношению к кванту времени. Сопрограммы связаны с параллельным исполнением ровно так же как и параллельное исполнение процессов/потоков связано с одноядерной, однопроцессорной системой. Но параллельность появляется тут уже не по отношению к кванту времени а по отношению к собственному исполнению сопрограммы.
> сильный акцент на производительности, больше сопоставимой по своим характеристикам с языком СА почему тогда в представленной таблице нет Си? Судя по ней, этот язык сопоставим по производительности с JS.
benchmark times relative to C++ (smaller is better).C++ compiled by GCC 4.2.1, taking best timing from all optimization levels (-O0 through -O3).
> C++ compiled by GCC 4.2.1маководы или бсдоиды, что ли? тут уже 4.7 на подходе, а у них всё пятилетней давности ископаемые.
> А почему тогда в представленной таблице нет Си? Судя по ней, этот
> язык сопоставим по производительности с JS.Да, сопостовим. Раза в три-четыре натянет - такая вот сопоставимость :)
ребята увидели Dylan и сразу нашли в нём Фатальный Недостаток. даже два: второй в том, что до конца выучить ниасилили.
Dylan, afaik, не поддерживается. Куда уж фатальней...
> Dylan, afaik, не поддерживается.да, вроде бы, развивается, но так, что со стороны это похоже на гальванизацию зомби. жаль, кстати, хорошая штука.
уважаемые, цены бы не было этой дискуссии, если бы пара-тройка сведущих просчитала бы конкретные примеры и сравнила результаты со всеми нюансами реализации, как это сделано где-то в середине этого обсуждения. многие, в их числе и я, нуждаются просто в выборе инструмента для математических расчетов подобного матлабу, который сегодня де-факто самый распространенный в данной нише. сейчас я пытаюсь использовать питон с библиотеками типа numpy, но вот появляются такие новшества вроде julia и думаешь, глядя на цифры из презентационной таблицы, стоит ли овчинка выделки? в уважением..
> нуждаются просто в выборе инструмента для математических расчетов подобного матлабуЕсли вам так нужен матлаб - ну и возьмите матлаб (octave, scilab, еще что-то - открытые).
> но вот появляются такие новшества вроде julia и думаешь, глядя на цифры из презентационной таблицы, стоит ли овчинка выделки?
Так разобрали же выше все "цифры". Там тупо сравнивается производительность "похожих" языковых конструкций.
В любом приличном месте за "код на Matlab" там представленный - убъют. Рекурсивные вызовы функций, for-циклы в самых неприличных местах. Не думаю, что там что-то от матлаба вообще осталось.
Прежде чем это можно будет реально использовать для мат.расчетов на замену матлабу пройдет лет 5 минимум. А пока это не более чем proof of concept. Если вы уж начали баловаться питоном, то смотрите в первую очередь на Sage как на замену матлабу. Поглядывайте временами в сторону pypy - как только там допилят numpy (утверждается что одна из основных задач на этот год), pypy+numpy станет убойной комбинацией по скорострельности и удобству. Кстати, numpy наконец то прикрутили и к Google App Engine.
спасибо за рекомендацию придерживаться python, sage конечно пробовал и даже использую. не могу сказать ничего плохого, т.к. для бесплатного софта возможности просто фантастические, но всегда есть навязчивая идея относительно повышения скорости
> фантастические, но всегда есть навязчивая идея относительно повышения скоростину вот к фримату в прошлом году без особого шума приделали jit компиляцию
Latest News - 2011-11-28 - FreeMat 4.1 Released
We are pleased to annouce the release of FreeMat 4.1. This version provides some significant performance improvements over FreeMat 4.0
New Just In Time (JIT) compiler -- the new version uses C++ as a backend for code generation, which means a much more substantial set of FreeMat code can now be JIT compiled. FreeMat uses CLANG-LLVM to provide run time compilation of the generated C++ code.
> ... многие, в их числе
> и я, нуждаются просто в выборе инструмента для математических расчетов подобного
> матлабу, который сегодня де-факто самый распространенный в данной нише. сейчас я
> пытаюсь использовать питон с библиотеками типа numpy, но вот появляются такие
> новшества вроде julia и думаешь, глядя на цифры из презентационной таблицы,
> стоит ли овчинка выделки? в уважением..Тебя какие расчёты и в какой области математики интересуют? В определённых областях есть хорошие альтернативы матлабу.
Ну вас всех послушаешь, зачем новый язык, зачем новый язык. А зачем хомячки тогда, ведь мыши есть. Природе наплевать на ваше мнение,она лучше знает что делать. Так что и новые языки будут и будут появляться - вполне закономерные процесс...
> Природе наплевать на ваше мнение,она лучше знает что делать.можно увидеть хотя бы один язык программирования, возникший не как результат умственной деятельности человека, а эволюционным путём — от стадии простейшего организма и далее?
> возникший не как результат умственной деятельности человека, а эволюционным путём — от стадии простейшего организма и далееОдно другому не мешает. Любой относительно молодой и популярный язык: python, ruby, их можно сравнить с более старыми perl, java, c и fortran, и с lisp, откуда понемногу тырятся ништяки, хотя прямого родства нет. Эволюция идет на уровне идей: удачные идеи заимствуются и распространяются в новых языках; биологическая эволюция протекает похожим образом. Беда в том, что на распространение идей сильно влияет коммерция, пиар/недостаток рекламы и всякие случайные факторы, так что не стоит думать, будто "волшебная эволюция" отсеет все недостатки существующих языков за обозримый период
>> возникший не как результат умственной деятельности человека, а эволюционным путём — от стадии простейшего организма и далее
> Одно другому не мешает. Любой относительно молодой и популярный язык: python, ruby,
> их можно сравнить с более старыми perl, java, c и fortran,Python появился в 90-м году, а Java 95-м. Учи матчасть!
Не знал, что питону столько :). Я не поклонник его, но, имхо, это только на пользу питону - появиться так давно и уже тогда иметь преимущества перед другими языками, даже появившимися позднее
Только его почему-то зарулили и Java и Perl. :-D Да и сейчас он как-то не блещет.
