Помогите выбрать язык программирования.

для анализа больших csv файлов

Смотря какой анализ, так может тебе просто AWK хватит.

Ну, ясно дело. Вообщем-то я говорил чисто теоретически и про прошлое. Сейчас времена поменялись сильно.

Народ верно говорит: «Скажи какой анализ?» А так, вообще, C# — вполне себе хороший вариант.

Эти самые условия нужно найти по историческим данным, которые у меня есть в csv формате.

Ну тогда бери R (как уже советовали) и не^W выеб^W анализируй. Потом напишешь алгоритм на чем знаешь.

С, С++ — не нравится «ручная» работа с памятью.

Джава это C++ без ручной памяти.

Rust — на мой взгляд переусложнили с unwrap(), например + зачем-то сделали 2 вида строк.

str и String не два вида строк. Они не синонимичны.

Наличие отладчика;
Понятный и легкий синтаксис.
Автоматическая уборка мусора. Руками освобождать память — усложнение кода.

Бери джаву и не выпендривайся

Жаба ваша запросто может оказаться медленнее пытона на такой задаче. Пока она раздуплится, пока прогреет ЖЫД, вычисления уже и закончатся. Уж если так важна скорость, только натив. И получается выбор то невелик. По-хорошему надо конечно плюсы брать и не выделываться, но ТСу тогда пару годков еще доучиваться. Хипстоту же сразу лесом. Пока он код напишет, они пять раз апи поломают. Нах такое счастье? Языки моложе 10 лет увы не годятся для серьезных задач.

да, да, пусть ТС трахается с плюсами

больших csv файлов

Что в твоём понимании является большим файлом?

C или Go то что тебе нужно.

Go или Clojure

Ada

Для примера, что сделано: на питоне

import csv

Pandas
/thread

Файл чуть меньше 2 ГБ.

Не подходит, мне нужно сделать много циклов for

А что значит «анализ»?

Файл чуть меньше 2 ГБ.

Так небольшой вроде.

мне нужно сделать много циклов for

А может не нужно? Ты алгоритмически пробовал задачу иначе решить?

подходит

Я хочу написать торгового робота для автоматической торговли на фондовой бирже. «анализ» — это поиск зависимостей по историческим данным, чтобы по этим зависимостям можно было предугадать дальнейшее изменение цены.

Там какие-то другие методы перебора данных есть?

лол. Писал такого на схеме.

java или c#

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

«анализ» — это поиск зависимостей по историческим данным, чтобы по этим зависимостям можно было предугадать дальнейшее изменение цены.

Из этого ничего не следует.

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

Зачем тебе csv-файлы-то анализировать мне не ясно.

Файл чуть меньше 2 ГБ

Значит, бинарное представление (после парсинга) легко влезет в ОЗУ, во всяком случае, если писать на С/С++. Твоя задача - выбрать нужную структуру данных и постараться сделать так, чтобы и сама структура данных, и алгоритмы работы с ней были cache-friendly.

PS. Судя по тому, что говоришь о каком-то ручном освобождении памяти в С++, с [современным] С++ ты не знаком от слова совсем.

Я хочу написать торгового робота для автоматической торговли на фондовой бирже. «анализ» — это поиск зависимостей по историческим данным, чтобы по этим зависимостям можно было предугадать дальнейшее изменение цены.

Язык программирования - здесь чуть ли не последнее дело, о чем нужно беспокоиться. Впрочем, питон будет медленным. Это бесспорно. Си/Си++ - явный перебор для непрофессионального программиста, да и для профессионального может быть тоже. Java или C# ближе к золотой середине: и дешево, и сердито, т.е. и удобоваримо по скорости исполнения, и терпимо по скорости разработки.

Тут может быть более важна математика, чем программирование. Какие-нибудь мартингалы, или ветвящиеся процессы, или тупо технический анализ. А что, на технический анализ опираются трейдеры и игроки, и уже поэтому или, может быть, исключительно поэтому, он иногда работает)) Хотя основные деньги зарабатываются и теряются во времена катаклизмов, а их предугадать почти невозможно. Вон, Сорос хвалился тем, что предвидел нарастающие противоречия. Именно это помогало ему зарабатывать состояния. Только я что-то отвлекся...

Кстати, а не подскажешь литературу или ссылки на тему автоматической торговли на фондовой бирже? Как надыбать такой файл CSV как у тебя?

Из нативных языков (т.е. без виртуальных машин) со сборкой мусора — D или OCaml. Можно и Go, но там, боюсь, значительную часть кода будут занимать проверки кодов возврата.

Если брать менеджед языки, то в первую очередь Java (можно Gosu или Ceylon, можно и Scala, но это эдакий монстр вроде C++ для JVM). Если же платформа позволяет использовать .NET, то C#.

Но если есть подозрение, что таки нужно будет выжимать самый максимум, то C++14 (или C++11, если нет возможности использовать самые последние версии компиляторов). В крайнем случае C.

Для технического анализа есть проф.инструменты. Тут похоже ТС курсовую пишет. Тоже дело, но можно не заморачиваться сишками.

Ну это херня как бы.

ниче не знаю, Go учить тебе быстро, а cython применить долго? кто-то врет тут.

Стандартные контейнеры и строки?

а вот это как раз может сожрать всю производительность. если уж обрабатывать «большие» файлы (2 гига - это мелкий файлик), то без STL однозначно. и главное - никаких там потоковых чтений файлов плюсовых, это гогно работает в сотни раз медленнее обычного fopen и fread. строки - тоже то ещё тормозилово. лучше с ними вообще не работать, а сразу всё в хэши переводить.
на плюсах тоже надо уметь писать. STL - это ходунки для детей. хотите скорости - пулы и самодельные аллокаторы в помощь. хотите ещё больше скорости - кастомные библиотеки ввода-вывода, которые превосходят стандартные в десятки раз. хотите ещё больше скорости - многопоточность и синхронизация через примитивы. ну а дальше уже идёт искусство настоящей оптимизации.

без STL однозначно

Никаких однозначно тут нет даже близко. При грамотном использовании std::vector, например, вполне годен и спасает от ручной возни с памятью.

никаких там потоковых чтений файлов плюсовых, это гогно

работает в сотни раз медленнее обычного fopen и fread

Это старая страшилка от тех, кто толком не разобрался в плюсовом IO. Для начала, не надо сравнивать жопу с пальцем. Плюсовым аналогом fread будет блочное чтение из std::filebuf, и никаких сотен раз там нет. И даже двух раз нет, как правило.

строки - тоже то ещё тормозилово. лучше с ними вообще не работать

Зависит. И да, почти везде есть small string optimization.

STL - это ходунки для детей. хотите скорости - пулы и самодельные аллокаторы в помощь

measure first

При грамотном использовании std::vector, например, вполне годен и спасает от ручной возни с памятью

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

Это старая страшилка от тех, кто толком не разобрался в плюсовом IO

расскажи это тем, кто поменьше меня опыта имеет в программировании на С и С++. или просто напиши банальный тест и прогони его. даже если там в 1.1 раз разница - это уже повод отбросить тормозную реализацию в пользу эффективности, если речь идёт про скорость. ладно там фигня в 2 гига. а если бы были сотни терабайт? вот там и вылезают все эти недоучтённые процентики.
все мои утверждения основаны на опыте. в том числе, разработке серверных приложений, которые обрабатывают огромные потоки данных. и я не один десяток раз измеряла разные функции, реализации, разные настройки оптимизации. так что меня не надо отсылать к измерениям. я их за 20 лет сделала предостаточно.
и да, вот ещё:
C++ Format - вместо стандартного I/O:
https://github.com/cppformat/cppformat
документация:
http://cppformat.readthedocs.org/en/stable/index.html
сравнительные тесты по скорости (сравнение со стандартными и другими популярными библиотеками):
https://github.com/cppformat/cppformat/blob/master/README.rst

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

Можно подумать, std::vector всегда используют так, что случаются реаллокации.

расскажи это тем, кто поменьше меня опыта имеет в программировании на С и С++

Твой опыт в С++ мало чего стоит, если сравниваешь fread с потоками. Всё равно, что сравнивать fread с printf. Что до тестов плюсовых потоков, их часто пишут люди, которые даже не слышали по tie и отключённую по умолчанию буферизацию. Вот они потом и рассказывают сказки про разницу в десятки или сотни раз.

не надо отсылать к измерениям. я их за 20 лет сделала предостаточно

Ещё как надо.

Можно подумать, std::vector всегда используют так, что случаются реаллокации.

ну, выдели 2 гига памяти (плюс накладные расходы на сам вектор) под него разом - не нужны будут аллокации. вообще, при обработке больших данных динамика полезна, в большинстве случаев.

Твой опыт в С++ мало чего стоит, если сравниваешь fread с потоками.

думаю, у меня более чем достаточно опыта. и мой опыт практический. у меня нет возможности жировать и разбрасываться ресурсами. я всегда выжимаю из железа всё, что оно может. так что я знаю, что говорю. ни одна реализация в плюсах не быстрее связки fopen+fread. можно играться с мапами, но там тоже свои особенности. где-то тут на ЛОРе буквально вчера обсуждался вопрос про мапирование и подводные камни, с ним связанные.
измерения проведи сам. это тебе домашняя работа. у меня более серьёзных задач достаточно. да, ещё не забудь про open/read. они простые, но шустрые.

У меня не для бирж, но похожая. В общем, изначально писаная на сишке + питон, но теперь неспешно переписываю на golang. Хз чем тебе не нравится многопоточность в нем.

Минуточку, не надо выкручиваться. Вот что ты написала

никаких там потоковых чтений файлов плюсовых, это гогно работает в сотни раз медленнее обычного fopen и fread

написать такое мог только человек, слабо знакомый с IO в плюсах, о чём уже было сказано. Если до сих пор не поняла, поток в C++ - это аналог printf/scanf. А не аналог fread/fwrite. Это первое.

Второе: «сотни раз» многое говорит о твоих так называемых измерениях. Десятки-сотни раз получаются только у чайников, не знакомых с плюсовым IO. Реальная разница в правильных тестах отнюдь не столь драматична, и не всегда в пользу C.

На этом вопрос о твоём «опыте» можно закрывать.

Если приложение будет работать 24 на 7, время-от-времени пожевывая CSV, то Java будет смотреться неплохо.

мне нужно сделать много циклов for

Stream.parallel() // optional
        .filter()
        .map()
        .reduce();

Второе: «сотни раз» многое говорит о твоих так называемых измерениях. Десятки-сотни раз получаются только у чайников, не знакомых с плюсовым IO. Реальная разница в правильных тестах отнюдь не столь драматична, и не всегда в пользу C.

Давай, ты же не чайник. Покажи мне векторы, строки и прочие куллстори из крестов. Предложи свои бенчмарки, придумай задачки. Покажи правильные.

Нафига? Всё равно сраные анонимусы обосрут.

Да, действительно, мне «бегать» по файлу не надо, нужно будет загрузить этот файл в оперативную память и потом работать с оперативной памятью.

Могу порекомендовать блог компании iiInvest

Из действующих торговых систем могу только порекомендовать систему Герчика, которая основана на линиях сопротивления и поддержки. Или производные от них. Эти линии чертят трейдеры исходя из своего опыта. Объяснить толком не могут.

По поводу литературы по анализу могу сказать, что не работает для успешной торговли фьючерсами: японские свечи, технический анализ на основе скользящих средних и всяких осциляторах.

У меня есть только данные по фьючерсам. Сейчас интернет медленный, если нужна информация по какому-то определенному фьючерсу, то могу вечером или завтра на эл. почту выслать. Если нужна информация по всем фьючерсам, то писал для себя такую штуку: https://bitbucket.org/dicos/moex_info/overview

А можешь дать ссылку на документацию?

https://github.com/ben-strasser/fast-cpp-csv-parser Я бы выбирал плюсы

Спасибо! Я только присматриваюсь к этой области. Думаю, а стоит ли тратить на нее свое время. Когда-то давно с другом написали небольшое приложение на Java для технического анализа. Было интересно. Все было новым для меня: и Java, и рынок ценных бумаг. Сейчас же нужен сильный коммерческий стимул)

Хочу спросить, а имеют ли смысл трейдинговые приложения под андроид? Или десктоп преобладает и будет преобладать?

Сейчас присматриваюсь к Go, но отталкивает поддержка многопоточности

но отталкивает поддержка многопоточности

что, прости?

Файл чуть меньше 2 ГБ.

Любой компилируемый, какой тебе больше нравится.

При грамотном использовании std::vector, например, вполне годен и спасает от ручной возни с памятью

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

std::vector<> так устроен, что реаллокация и копирование каждого элемента происходит _в_среднем_ не более одного раза. Для подавляющего числа приложений этого более, чем достаточно.

Microsoft R.

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

JavaScript тебе самое то! :-)

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