BZ>а ты сможешь ему обеспечить привычную по мегаполису среду существования? я не просто так спрашиваю, дело в том, что учёные проводили эксперименты и выяснили, что выходцы из крупных городов в отсуствии смога гибнут через 2-3 месяца
Со смогом тут очень плохо.
Солнце, море. Температура в течении года колеблется в районе +21C, хотя летом куда жарче.
Здравствуйте, Joel Reymont, Вы писали:
JR>Со смогом тут очень плохо.
JR>Солнце, море. Температура в течении года колеблется в районе +21C, хотя летом куда жарче.
JR>Как пить дать загнется!
короче, портфель не может быть совсем огромным. столько контрактов в мире нет Сильно сомневаюсь что размер портфеля превысит 10000 инструментов, и уверен, что на самом деле их в районе 1000.
На одной бирже торгуется порядка сотни тысяч инструментов, и это можно без проблем обработать в эрланге.
G>>Мне кажется, можно и с Эрлангом. Аналитику подцеплять драйвером, и писать на чем угодно, неважно, а Эрланг обеспечивает масштабируемость и отказоустойчивость.
JR>Можно и драйвером подцеплять, хотя клиент желает аналитику менять без перекомпиляции всей системы.
Не проблема подцеплять аналитику через Dll. А если хватит производительности, то можно завернуть ее в С-Node.
JR>На самом деле, я не вижу почему данную систему обязательно писать на Эрланге, знаю успешные примеры применения OCaml в этой области (смотри здесь)и просто хочу попробовать.
В этом примере идет речь о торговых роботах. Насколько я понимаю, это не совсем то, что у тебя. Торговые роботы — довольно специфическая вещь вообще, и не слишком сложная сама по себе.
JR>Масштабируемость и отказоустойчивость это само собой, но что насчет работы с time series размером в миллионы элементов?
Торговые роботы не работают с такими длинными сериями. Они реагируют на отдельные котировки. Прогонять их на истории (Backtesting) — решается записью и прогоном фида.
В остальном — миллионы котировок делятся на торговые сессии, и стратегии четко делятся на Intraday и Historical. То есть, с миллионным временным рядом как единым целым тебе иметь дело не придется.
>Как представлять в Эрланге эти самые time series? Как tuples, binaries?
Есть масса вариантов. Один список рекордов на сессию. Или последовательность сообщений. Короче, с этим принципиальных проблем нет.
>Как проходить по ним функционально (map, fold)?
Сделать свой аналог Foldl, Который может работать на самой кривой структуре, на самом деле.
С теми же самыми проблемами ты столкнешься и в окамле, кстати. Никуда они не денутся. И решатся будут примерно так жк.
>То что математика в Эрланге страдает это давно известно, а двигать прогресс на примере этого проекта я не готов.
Математику можно как раз подцеплять внешнюю, делая ее на окамле или с++.
Здравствуйте, Quintanar, Вы писали:
Q>Зачем изобретать велосипед, если есть специализированные продукты? Тот же kdb+, где и язык к тому же функциональный. Правда, лицензия стоит денег.
Она не просто стоит денег, она стоит БОЛЬШИХ денег. Скажем, $40К за процессор, с минимальной покупкой в 4. Плюс, я пробовал попросить у них пробник, но мне не дали. Показали пальцем на конкурирующий продукт, который я собирался изобрести .
Я забыл ответить на вопрос... Если я изобрету этот велосипед за год, то овчинка уже будет стоить выделки.
По запросам желающих, у меня складывается впечатление что программисты в регионах и бывших республиках получают по $3.5К и больше в месяц. Даже если выдавать желаемое за действительное, то все равно можно собрать команду из нескольких человек и написать что-нибудь подобное. Кстати, рекомендую посмотреть на MonetDB.
Здравствуйте, Joel Reymont, Вы писали:
JR>Она не просто стоит денег, она стоит БОЛЬШИХ денег. Скажем, $40К за процессор, с минимальной покупкой в 4. Плюс, я пробовал попросить у них пробник, но мне не дали. Показали пальцем на конкурирующий продукт, который я собирался изобрести .
Да, дорого. Думал, что за 40 все-таки можно взять. Но она того стоит.
MonetDB отличается в некоторых местах в нелучшую сторону — хоть и column based, но порядок записей все равно не фиксирован и поддерживается только SQL. Язык в kdb+, я считаю, является главным ее преимуществом в полном соответствии с известной статьей Грехема. Пока конкуренты поддерживают только SQL или неуклюжие довески типа PL-SQL, акционерам kx бояться нечего.
Здравствуйте, Quintanar, Вы писали:
Q>MonetDB отличается в некоторых местах в нелучшую сторону — хоть и column based, но порядок записей все равно не фиксирован и поддерживается только SQL. Язык в kdb+, я считаю, является главным ее преимуществом в полном соответствии с известной статьей Грехема. Пока конкуренты поддерживают только SQL или неуклюжие довески типа PL-SQL, акционерам kx бояться нечего.
А можно пояснить, что под выделенным имелось в виду?
Здравствуйте, Курилка, Вы писали:
К>А можно пояснить, что под выделенным имелось в виду?
У Пола Грехема есть статья, где он рассуждает на тему ЯП. Там он утверждает, что Лисп был главным конкурентным преимуществом их компании, что они не сильно волновались, когда появлялись конкуренты, заявлявшие, что они используют что-то типа С++. Q в kdb обладает похожими свойствами, пока конкуренты прикручивают что-то через (O|J)DBC к обычной БД, ты пишешь тоже самое за 5-ть минут на Q.
Здравствуйте, Quintanar, Вы писали:
Q>MonetDB отличается в некоторых местах в нелучшую сторону — хоть и column based, но порядок записей все равно не фиксирован и поддерживается только SQL.
А что значит порядок записей не фиксирован? Можно подробнее?
Прошу прощения, что вмешиваюсь в ваш разговор, но вот не совсем понял:
JR>По запросам желающих, у меня складывается впечатление что программисты в регионах и бывших республиках получают по $3.5К и больше в месяц.
Т.е. вы получили несколько резюме от соискателей, который проживают в регионах и которые просят от $3.5 и выше за эту работу?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Joel Reymont, Вы писали:
JR>А что значит порядок записей не фиксирован? Можно подробнее?
Я имел в виду то, что там (как во всех обычных БД) порядок записей в БД не специфицирован, т.е. ты не знаешь заранее, как именно физически новая запись будет расположена относительно уже существующих. Это не очень удобно, когда заранее известно, что у данных есть естественный порядок (для финансовых данных — это время). В kdb+ порядок записей всегда известен и меняется детерминировано, это позволяет производить над данными вычисления, недоступные в обычной БД (вычислять n-й элемент, сравнивать соседние по порядку элементы и т.п.).
Вот недавно, как раз, интересовались этим:
---------
А>Выбрать все акции цена на которые в один день поднялась на 10 пунктов А>на второй день опустилась на 15 пунктов А>а на третий день поднялась на 30 пунктов А>можно ли такие запросы эффективно делать ?
Если есть предвычисленная база всех статистических параметров типа priceData = (date; stock; open; close; hi; low; vwap; ... ), то элементарно:
Через временную таблицу:
select stock from (select flag: (10 -15 30)~close-open by stock from priceData where date in (d-til 3)) where flag
или одним запросом:
select distinct stock from priceData where date in (d-til 3), (~[10 -15 30]; close-open) fby stock
---------
За счет того, что priceData упорядочена по времени, запросы получаются элементарными и работают очень быстро.
Здравствуйте, Quintanar, Вы писали:
Q>Здравствуйте, Курилка, Вы писали:
К>>А можно пояснить, что под выделенным имелось в виду?
Q>У Пола Грехема есть статья, где он рассуждает на тему ЯП. Там он утверждает, что Лисп был главным конкурентным преимуществом их компании, что они не сильно волновались, когда появлялись конкуренты, заявлявшие, что они используют что-то типа С++. Q в kdb обладает похожими свойствами, пока конкуренты прикручивают что-то через (O|J)DBC к обычной БД, ты пишешь тоже самое за 5-ть минут на Q.
Наверное эта. Да, согласен, есть такой факт, получается что-то типа legacy не только в коде, а и в сознании
Здравствуйте, eao197, Вы писали:
E>Т.е. вы получили несколько резюме от соискателей, который проживают в регионах и которые просят от $3.5 и выше за эту работу?
Здравствуйте, Joel Reymont, Вы писали:
JR>Здравствуйте, eao197, Вы писали:
E>>Т.е. вы получили несколько резюме от соискателей, который проживают в регионах и которые просят от $3.5 и выше за эту работу?
JR>Люди хотят получать $20 в час. Я их не виню.
Молодцы, однако! Зря что ли сидя в провинции они Erlang учили?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Quintanar, Вы писали:
Q>Зачем изобретать велосипед, если есть специализированные продукты? Тот же kdb+, где и язык к тому же функциональный. Правда, лицензия стоит денег.
Это сложно понять наверно, но это делают затем, чтобы заработать денег. При внешней похожести продукты могут (и будут) сильно отличаться позиционированием — порой играют довольно тонкие различия. У любого продукта также есть сильные и слабые стороны, на которых можно и нужно сыграть. Маркетинг найдет слабые стороны в продуктах конкурентов, и обязательно повернет их себе на пользу, сместив позиционирование (делается это кстати не сложно — есть технология). Наличие конкурентов не только не остановит другие компании от вхождения в рынок, но и является фактором, снижающим риски. Если у тебя конкурентов нет, то
1) это означает отсутствие сформировавшегося рынка, и очень затруднительно достоверно оценить его объем. А это означает, что любая разработка с большими вложениями чрезвычайно рискована. Рынок может быть элемеентарно не готов к твоему решению, если ты опередишь потребности рынка на пару лет — ты пролетишь. Выходить с продуктом надо вовремя. Ты должен очень хорошо представлять себе сбытовую часть в этом случае.
2) Также, отсутствие конкурентов и аналогов афигенно затрудняет анализ требований. Тебе в разы сложнее оценить тенденции пользователей и их потребности.
Функциональность языка программирования как раз на потребительских ТТХ не сказывается. Почему такая штука, написанная на Эрланге, может иметь преимущество перед остальными существующими решениями, я естественно объяснять не буду. Это элемент технологической стратегии, которую на форумах не обсуждают. Достаточно того, что я сам это понимаю.
Здравствуйте, Joel Reymont, Вы писали:
JR>По запросам желающих, у меня складывается впечатление что программисты в регионах и бывших республиках получают по $3.5К и больше в месяц. Даже если выдавать желаемое за действительное, то все равно можно собрать команду из нескольких человек и написать что-нибудь подобное. Кстати, рекомендую посмотреть на MonetDB.
Цена целовекомесяца в нашем воронежском офисе (зарплата плюс все косвенные издержки офиса пропорционально) примерно 1500 K USD. Она достаточно типична для Воронежа. Зарплата 30К RUR для Воронежа считается очень хорошей. Воронеж — город с миллионом человек населения.
Средняя зарплата вменяемого инженера по москве — 2000-3000 USD чистыми, небольшой процент получает до 4К, выше — это сказки HR. То есть, 3500 в месяц — это нормально для очень хорошего инженера, по меркам москвы.
Зарплаты в Питере всегда были раза в полтора меньше, чем в Москве. Делай выводы.
Насчет outsourcing rates. Luxoft (Москва) продает час примерно по 32$ — это верхняя планка. Нормальное колебание рейта для России — 25-35 долларов. Компания, которая оказывает услуги, будет иметь нормальные характеристики если они в фонд зарплаты отдают совокупно чистыми (после всех налогов) не более трети выручки. Более половины выручки она отдавать ваще не может — концы с концами не сойдутся. Считай среднюю зарплату аутсорсеров.
Здравствуйте, Gaperton, Вы писали:
JR>>>Люди хотят получать $20 в час. Я их не виню.
E>>Молодцы, однако! Зря что ли сидя в провинции они Erlang учили?
G>Эрлангу можно научить даже осла, причем в короткий срок — это не С++. Деньги платят за мозги в голове.
Если кто-нибудь в провинции самостоятельно взял да и выучил Erlang для себя (а здесь, в одной из провинций нифига за Erlang не платят), то это с очень большой долей вероятности говорит о наличии мозгов в голове.
G>Кстати, уверен на 98%, что Эрланга по настоящему большинство из них не знают — то есть систему крупную они грамотно спроектировать для него не смогут.
Это уже их проблемы.
И боюсь, что не все отлично разбирающиеся в Erlang-е программисты смогут грамотно спроектировать крупную систему. Имхо, знание языка и умение проектировать -- вещи, как минимум ортогональные. А иногда и взаимоисключающие
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
. На яхту не останется.
