Язык Q, KDB+

Язык Q, KDB+.
Имхо самый быстрый и идеальный, для математики.
Синтаксис только не си.
Сайт http://kx.com/kdb .php

Q is a proprietary array processing language

это уже, как минимум, печально

Ну так это «Серьезный язык».

ТС, я сегодня читал про отличный язык для вычислений. http://chapel.cray.com/ Все само параллелится.

Для научной работы лучше всего подходят специальные научные пакеты. Про python+numpy/scipy выше уже писали. Прекрасный скриптовый язык с кучей доступных научных библиотек.

Если нужен компилируемый язык, то кроме фортрана даже и не знаю что предложить.

> * интуитивность, простота синтаксиса

fortran

* серьезность, не .Net

fortran

* кроссплатформенность ( разработку буду вести под линуксом, презентовать придется под вендой )

fortran

* быстрота работы, скорость разработких

fortran

* желательно си-подобный синтаксис, но не С*

* удобная математическая библиотека

До**я разных.

Для начала надо определиться, что такое «научная работа».

Если нужна числодробилка, то тут вряд ли что-то сможет переплюнуть Matlab/Octave. Не смотря на то, что это интерпретируемые языки, базовые функции типа FFI написаны на Си очень хорошо оптимизированы. Более того, можно использовать матлабовские функции в сишных программ.

Если вы занимаетесь нейросетями или там работаете в области плохо формализуемых задач, то тут лучше выбрать коммон лисп.

>серьезность, хорошая репутация — false
true, мнение школоаналитиков с лора не в счёт.

кроссплатформенность — false

true, кросплатформенней тяжело найти

Octave/Matlab или R - это два дефолт-языка для всякой научной математики.

Блин, по всем же пунктам, сразу бы написал что тебе нужна Java.

серьезность, не .Net

facepalm.tar.xz

ООП умрет, максимум лет через 5, вернется процедурная парадигма

Вот это уже хороший вброс. Хотя, конечно, растущая популярность anemic domain model и прочих service oriented architecture заставляет задуматься.

Если вам нужна серьезная математика, то вам стоит обратить внимание на Haskell все-таки. Erlang бы идеально подошел, если бы не это условие. В Erlang традиционно слабая реализация математических операций и функций. Хотел было посоветовать OCaml, но потом решил, что синтаксис там совсем не из легких.

>Вот это уже хороший вброс.

Если бы. Это очень печально, вообще-то. ООП, по крайней мере мейнстрим, превратился в жуткую гуманитарщину. Как результат - контрпродуктивные стратегии обучения и неминуемая каша в головах.

Вдвойне обидно когда жуткую помесь ООП и ООД выдают за «парадигму» программирования.

>то вам стоит обратить внимание на Haskell все-таки

Не стоит. Как его адепт говорю, не стоит.

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

fixed?

Не выебывайся, используй специализированные мат. пакеты. Ту же Wolfram Mathematica.

Вот это Тролль! Давненько таких тут не видел =)

Осиль уже хотя бы страничку о Erlang на Википедии, чтобы не писать больше такую ерунду. Там тебе конкретно объяснят, почему у этого языка синтаксис проще некуда, почему он при всей своей медлительности может работать быстрее многих (и быстрее Си в том числе) и почему этот язык истинно кроссплатформенный.

P.S. почему приведенный тобой код для меня совершенно понятен, хотя я еще не дочитал книгу по Erlang и до сих пор не знаком с синтаксисом обмена сообщениями между узлами?

> почему у этого языка синтаксис проще некуда

Как раз синтаксис у эрланга очень сложен по сравнению с другими языками.

no.

в бытность школьником, изучал паскаль по книжке, в которой вторую половину C++ занимал, и ничего, нормально было понятно.

Python, очевидно же. Где не будет хватать производительности, там Cython.

python

А вообще ты зря отказывается от C#, я в него влюбился, когда писал на нем.

> Вот это уже хороший вброс.

Если бы вброс, обычная правда жизни. Современный софт никуда негоден, в большей степени по вине программеров.

> помесь ООП и ООД выдают за «парадигму» программирования.

Обидно когда парадигму программирования искуственно делят на «объектно ориентированное программирование» и «объектно ориентированный дизайн», что по сути своей одно и то же.

И да:

интуитивность, простота синтаксиса

Синтаксис очень простой и понятный.

серьезность, не .Net

Основная реализация работает не на дотнете.

кроссплатформенность

Еще какая.

быстрота работы

Достаточна, но при необходимости можно писать модули на C/Cython.

скорость разработки

Замечательная.

желательно си-подобный синтаксис, но не С*

Не очень C-подобный, но ближе, чем всякие лиспы.

удобная математическая библиотека

Завались.

>интуитивность, простота синтаксиса

желательно си-подобный синтаксис, но не С*

ты уж определись

удобная математическая библиотека

какая область математики?

>то по сути своей одно и то же.

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

Ничто тебе не мешает использовать концепцию «класс-как-модуль». И в некоторых, особенно низкоуровневых, библиотеках этак концепция ой как используется. А это уже скорее структурный подход.

fortran

/thread

Java/Scala. Профит скалы в том что код короче и параллелизм проще пареной репы

а на какую тему работа?
а так, схему бы посоветовал. и на Си отдельные модули написать.

C++/Qt. Qt скроет от тебя всякую низкоуровневую хрень. Нативный код, энтерпрайзность и кроссплатформенность и кроссплатформенная IDE QtCreator в наличии.

удобная математическая библиотека

libgmp? Быстрая, документированная, кроссплатформенная, нативная.

Хватит форсить это мертвое говно.

Плюсую к питону.
- интуитивность, простота синтаксиса
Язык с более простым синтаксисом найти очень трудно
- кроссплатформенность ( разработку буду вести под линуксом, презентовать придется под вендой )
Интерпретаторы есть и под линь, и венду, и макось.
- быстрота работы
Вот тут загвоздка. Но, всё зависит от задачи.
- скорость разработки
Имхо, наивысшая среди всех языков.
- желательно си-подобный синтаксис, но не С*
Не нужно.
- удобная математическая библиотека
Имеется.

фортран еще всех нас переживет! и по производительности уделает всех как бог черепаху.

> по производительности уделает всех как бог черепаху

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

ТС при такой общности можно рекомендовать matlab или python. Но высокой производительности с ними добиться сложно. Фортран не люблю: из-за совместимости со старыми версиями в нем много костылей и ненужностей. А таких простых вещей, как число пи, - нет; жутко нестройный, но матрицы считает хорошо. Короче, для того, чтобы просто работало, а как - не важно. Если нужно сложного, но гибкого - Си. Первых глав К&Р достаточно, чтобы понять, что язык простой, правда, слишком низкоуровневый.

фортран

Только фортран!

>ТС, я сегодня читал про отличный язык для вычислений. http://chapel.cray.com/ Все само параллелится.

Все само параллелится в OpenMP, а там насколько я понял в пределах одного хоста только синтаксический сахар над POSIX threads.

Да, и Intel Fortran почти во все пункты. http://software.intel.com/en-us/articles/non-commercial-software-download/ А под Виндой презентовать можно на триальной версии.

> ООП умрет, максимум лет через 5, вернется процедурная парадигма

Что ты курил?

python-3.2

А `nial', или он совсем неживой? (исходники как-то найти пытался)

К зато открыли, правда (насколько я понимаю, так как почти не пользовался) все равно он намного более нишевый, нежели APL/J.

> разве бывает синтаксис более интуитивный и простой чем в лиспе?

Pascal, Scheme, Lua, Standart ML (вроде).

Так может таки C?

scheme это и есть lisp, а в остальных синтаксис сложный

> а в остальных синтаксис сложный

http://lua-users.org/wiki/LuaGrammar (внизу страницы), имо довольно компактная грамматика, у скобочек - макросы => синтаксик однородный, но предсказуемость кода - не факт.

Правда остальные (кроме схемы) для общего случая мало применимы.

разве что у них есть всякие плюшки типа data view, локалей. Все семантично и ни шагу в сторону. Больший размах для оптимизации. А так все стандартные _map, _grep, _fold

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

Простейшие замеры показывают, что фортран заруливает си достаточно сильно (сравнивал gcc, gfortran). Связано с тем что в си сложности с обозначением, что этот указатель относится к одному массиву, а этот к другому и поэтому многие оптимизации нетривиальны или просто недоступны, а так же вроде бы (могу соврать) есть некая разница в построении циклов.

Еще причина для выбора фортрана это то, что для число-дробилок си слишком переусложнен и излишен.

Если уж выбирать что-то кроме фортрана, то тогда уж лучше с++ (в надежде, что шаблоны позволят писать меньше кода) или fortran + скриптовый язык (питон или матлаб). Второй вариант, конечно, предпочтительнее но надо учить два разных языка вместо одного.

И да, «научная работа» понятие весьма растяжимое. Чем конкретно будете заниматься? А может вам вообще лучше хаскель или лисп использовать.

>серьезность

Fortran 77