Но на ООП я смогу сделать и отчет, и поток обработать. А на ФП, выходит, не могу? То есть чтобы создать не консольную программку, а что-то посерьезнее, мне нужно два языка?
А много вы промышленных языков знаете, которые умеют ФП и не умеют ООП или наоборот?
Да, он чисто для UI на клиентах, для данной схемы этот шаг не нужен, хотя в реальности он конечно же происходит. В ядре уже есть инфа о том что ставки остановлены.
Сетевая задержка vs скорость реакции человека. Хз, кто выиграет :).
Вы не поняли.
Чтобы информация о голевом моменте появилась у букмекера необходим такой набор действий (предположим наступает опасный голевой момент, надо инициировать остановку ставок):
1) Скаут на матче сидит с телефоном (планшетом) и тыкает в кнопки, посылая сообщения АГГРЕГАТОРУ данных. Это даже не букмекер. У букмекера есть свои скауты, но их кол-во ничтожно мало по сравнению со скаутами которые есть у агрегаторов.
2) Сообщение идёт по сети (в начале мобильной, т.к. на трибуны никто кабель не проводит, потом по кабелям).
3) Сообщение обрабатывается логикой агрегатора
4) Сообщение по сети отправляется букмекерам
5) Сообщение обрабатывается логикой букмекера
6) Сообщение об остановке ставок отправляется по сети на клиенты (сайт, мобилки и т.п.)
Давайте посчитаем кол-во задержек в этой цепочке
Реакция скаута + Сетевой лаг + Лаг логики (обработка сообщения в системе не мгновенная) + Сетевой лаг + Лаг логики + Сетевой лаг.
Теперь прикинем что надо сделать клиенту букмекера чтобы сделать ставку под гол:
0) Чуть загодя вбить в поля сумму ставки и вид пари
1) Среагировать вовремя
2) Нажать на кнопку
Т.е. просто реакция + сетевой лаг + лаг логики.
Да, у каждого кэфа есть время жизни и он может протухнуть, но я не об этом.
Без особых ухищрений такие ставки бы проходили, т.к. человек на стадионе реагирует КОНЕЧНО же быстрее чем букмекер.
Спасибо что пытаетесь мне рассказать как там у букмекеров дела идут. Повторюсь я работал в букмекерской компании, прям работал в отделе букмекерского ядра.
Я могу рассказать вам не частные случаи, а общую картину.
Практика:
Достаточно поменять коеффициенты на 20% и у вас уже толпа surebetter-ов развернёт ставки в другую сторону, Вы просто сбалансируетесь с конкурентами.
Такое тоже возможно, но на практике отключают такие исходы. За подтверждением далеко ходить не надо, зайдите под конец матча, где разрыв по счету более 2х очков, на сайт любого букмекера и попробуйте поставить на почти-победителя.
есть толпа фанатов, которые поставят на Спартак при любой ставке.
Это только кажется что это толпа. Основная аудитория букмекера — маргиналы, а в РФ это жители соседних республик. По сравнению с ними фанатов Спартака ничтожно мало. Опять таки, за подтверждением посетите заведение любого букмекера, посмотрите контингент. И если вы думаете что в интернете лучше, то нет.
Для хорошего букмекера это не минус и не банкротство. Это инвестиция.
Минусовые матчи случаются постоянно, да. Если быть наивным букмекером, то они приведут к банкротству. На долгой конечно покрываются статистикой, если букмекер прошаренный.
На практике букмекеры платят (и много) за почти-реалтайм фид.
Опять таки, спасибо что рассказали мне.
Я больше скажу, платят даже за 2 и более чтобы предотвратить риски что один накроется. Даже эти реалтайм фиды (которые идут от скаутах на матчах) не могут быть быстрее (в силу банальной сетевой задержки) чем человек который СИДИТ НА СТАДИОНЕ. Ставки "под гол" идут постоянно.
А ещё кучу денег букмекер делает на неосновных ставках, вроде «кто пробьет следующий угловой»
Это не так. 90% ставок в РФ — футбол. А 90% из них это три вида пари — 1х2, фора и тотал.
Все эти динамические пари они для показухи больше, что букмекер с широкой линией, денег там нет совсем.
Ещё раз спасибо что пытаетесь мне рассказать "как там у букмекеров", но я лучше знаю.
Ничего они не оценивают. Они назначают коэффициенты таким образом, что бы проигравшая сторона полностью оплачивала выигрыш счастливчиков. И себе % конечно же.
Полная чушь. Работал в этой сфере прям в мякотке букмекерства.
Люди заносят на фаворитов.
Возьмём Спартак-Реал. Какой бы кэф вы не поставили на Спартак, сумма денег (плечо) там будет на порядки меньшая чем баблище на Реале (гарантированный выигрыш даже с кэфом 1.1). И занесённые триллионы на Реал надо ОТДАТЬ с кэфом 1.1
Внимание вопрос, где тут выигрыш для букмекера? Ответ скажу за вас — тут чистый минус на грани банкроства.
В реале такие высоковероятные исходы отключают, чтобы выровнять "плечи".
Другой пример: играют Мухосранск-Задрищенск. Вялый матч, никто не может оценить силы этих дворовых команд, поэтому ставите 50/50 с небольшой маржой(т.е. кэфы будут 1.9 у обоих например) и тут внезапно на Мухосранск прилетает ставка в 10 лямов. Ваши действия как букмекера? Правильный ответ — НЕ принимать такую ставку, т.к. это явный договорняк и вы залетите на выплату почти 20 лямов.
Ещё пример. Кто-то сидит на стадионе и получает инфу о голевых моментах раньше логического ядра букмекера. Вот он видит что Месси вышел один на один с вратарём и пробивает. До гола ситуация на поле была равная, шансы на победу каждой команды были допустим тоже 50/50, после гола они очевидно изменятся, поэтому вы можете в последний момент поставить с ОЧЕНЬ выгодным кэфом за момент до его падения.
Короче, ещё многое можно рассказать, а многое не надо. Но главная мысль — не надо путать букмекерство и тотализатор.
В тотализаторе — собрал деньги с народа, выплатил другой половине за минусом маржи. И у нас в РФ тотализатор запрещён.
Чтобы заработать на букмекерстве, где тебя все пытаются обмануть, надо некисло работать с реалтайм данными и менеджментом рисков.
Я не вижу смысла продолжать дискуссию… ответьте, какие из перечисленных Вами языков кроме Haskell компилируются в машинный код и почему все они достаточно маргинальны по сравнению с Go?
Противоречивые параграфы вижу я, но ладно :)
GHC у Хаскеля умеет компилировать как в натив, так и под LLVM
FSC в F# умеет компилировать только под CLR, но есть такая штука как .NET Native, которая сразу полученный код для CLR гонит в натив. Не пользовался за ненадобностью.
В JVM тоже есть способ гнать байткод в натив — Excelsior например.
Не буду скрывать, нативный бинарник Go получится крайне маленьким по размеру по сравнению с любым из вышеперечисленных, но это из-за скудности стандартной либы Go (и это слабо сказано), а не потому что там какие-то ядерные оптимизации происходят.
По поводу маргинальности — PHP и Питон тоже популярнее Haskell, F# и Clojure. Да и вообще всех ФП языков. Возможно даже вместе взятых.
Делает ли это Haskell, F# или Clojure плохими языками? Для тех кто не осилил их освоить — несомненно.
Происходит качественный скачок — появление и позиционирование языка Go для решения этих проблем. Язык заточен исключительно под предметную область: объединяет модель multi-threading и async concurrency — программа запускается в несколько потоков, которые в свою очередь обрабатывают очередь задач (goroutines)
Я понимаю что гоферам застилает глаза божественность Пайка, но неплохо мы обзнакомиться с теорией.
Языки, в которых в самом синтаксисе была селективная асинхронность с синхронным общением между легковесными тредами и корутинами:
Concurrent ML + Parallel CML
Racket
Не говоря уж у тонне либ для языков:
Haskell — дофига. Control.Concurrent.CML хотя бы! Control.Concurrent.CHS туда же.
F# — Hopac
Clojure — core.async
Не поверите, везде одно и то же — собственный шедулер в юзер спейсе, n:m модель, легковесная абстракция над ОС тредами, синхронное общение (ченелы), селективная асинхронность.
Что нового привнёс Go? Убрал с гоферов необходимость учить Haskell, F# или кложу. Про CML я просто молчу, старый язык уж очень, хотя он до сих пор где-то в продакшне телекома юзается по слухам.
Качественный скачок — новый специализированный язык, поддерживающий многозадачность из коробки.
Поддерживающий только ОДНУ парадигму многозадачности (корутины) из коробки, и оберачивающий весь синтаксис на фоне в монадку Async, чтобы блокирующие вызовы байндились на континуейшн как будто это императивный код.
Любой нормальный язык даст вам на выбор другие парадигмы многозадачности: треды, корутины, фиберы. Монадки конечно же любые на выбор (без дженериков в Го их не сделать, поэтому захардкожена одна), на выбор вытесняющие или кооперативные юзер-спейс планировщики.
Это всё из Го убрали чтобы среднему гоферу не надо было мучаться проблемами выбора.
Для каких-либо других систем (например, для системы типа шарпа) Хиндли-Милнер уже неприменим.
Я не уверен что до конца понимаю почему нормальный вывод типов нельзя подключить к C#
С чего бы вдруг? Там точно так же мог бы быть string иди HurrDurr. То, что должен быть Int32 — вообще ниоткуда не следует. Что будет, если ниже я напишу foo = "fdfdsfd"?
Ну если мы о C#, то да, никак.
А вот тот же H-M алгоритм же с бектреком. Все ограничения от литералов и функций он применяет взад) В этом например отличие алгоритма вывода в Scala от HM, она не умеет пропагировать типы по коду выше.
На нем можно писать как на C#, но приходится это делать явно и не очень удобно.
Лоу левел вещи (unmanaged и ко) действительно писать не так удобно как на C# (но возможно, и даже stackalloc есть, а недавно и Span завезли), но это даже для C# неидеоматичный код так-то! Для любителей поиграться с поинтерами в менеджд языке сойдёт.
А вот обычный ООП код (интерфейсы, пропертя, классы, абстракные фабрики фабрик синглтонов) писать на нём получается короче чем на C#. Потому что возможностей больше. У меня даже примеры есть)
В смысле? Я чот не понял наверное.
F# как раз поможет со всеми задачами, в которые, например, C# умеет.
И многие решает проще.
Да вот сразу пример (с гифками):
https://github.com/Zaid-Ajaj/tabula-rasa
А много вы промышленных языков знаете, которые умеют ФП и не умеют ООП или наоборот?
Не совсем 4х, но AI в EU4, пожалуй, лучший в сингл плеер стратегиях.
Может ещё и Силы не существует? Вздор какой.
там кнопка сверху есть, которая перезапускает страницу, сохраняя прогресс. Мне помогло
Никак, это фантазии на уровне пропозала. Как и тайп классы.
Даже не факт что рекорды въедут в C#8
Рекомендую узнать что значит /s
Очень здорово что вы всё русскоязычное комьюнити назвали нецивилизованным на основании одного спора в интернете.
Да, он чисто для UI на клиентах, для данной схемы этот шаг не нужен, хотя в реальности он конечно же происходит. В ядре уже есть инфа о том что ставки остановлены.
Вы не поняли.
Чтобы информация о голевом моменте появилась у букмекера необходим такой набор действий (предположим наступает опасный голевой момент, надо инициировать остановку ставок):
1) Скаут на матче сидит с телефоном (планшетом) и тыкает в кнопки, посылая сообщения АГГРЕГАТОРУ данных. Это даже не букмекер. У букмекера есть свои скауты, но их кол-во ничтожно мало по сравнению со скаутами которые есть у агрегаторов.
2) Сообщение идёт по сети (в начале мобильной, т.к. на трибуны никто кабель не проводит, потом по кабелям).
3) Сообщение обрабатывается логикой агрегатора
4) Сообщение по сети отправляется букмекерам
5) Сообщение обрабатывается логикой букмекера
6) Сообщение об остановке ставок отправляется по сети на клиенты (сайт, мобилки и т.п.)
Давайте посчитаем кол-во задержек в этой цепочке
Реакция скаута + Сетевой лаг + Лаг логики (обработка сообщения в системе не мгновенная) + Сетевой лаг + Лаг логики + Сетевой лаг.
Теперь прикинем что надо сделать клиенту букмекера чтобы сделать ставку под гол:
0) Чуть загодя вбить в поля сумму ставки и вид пари
1) Среагировать вовремя
2) Нажать на кнопку
Т.е. просто реакция + сетевой лаг + лаг логики.
Да, у каждого кэфа есть время жизни и он может протухнуть, но я не об этом.
Без особых ухищрений такие ставки бы проходили, т.к. человек на стадионе реагирует КОНЕЧНО же быстрее чем букмекер.
Если степень доверия моим словам зависит от количества нулей в кэфе, то вот вам кэф ДАЖЕ с 10ю нулями!
1.0000000001
Теперь верите что я в мякотке работал?
/s
Спасибо что пытаетесь мне рассказать как там у букмекеров дела идут. Повторюсь я работал в букмекерской компании, прям работал в отделе букмекерского ядра.
Я могу рассказать вам не частные случаи, а общую картину.
Такое тоже возможно, но на практике отключают такие исходы. За подтверждением далеко ходить не надо, зайдите под конец матча, где разрыв по счету более 2х очков, на сайт любого букмекера и попробуйте поставить на почти-победителя.
Это только кажется что это толпа. Основная аудитория букмекера — маргиналы, а в РФ это жители соседних республик. По сравнению с ними фанатов Спартака ничтожно мало. Опять таки, за подтверждением посетите заведение любого букмекера, посмотрите контингент. И если вы думаете что в интернете лучше, то нет.
Минусовые матчи случаются постоянно, да. Если быть наивным букмекером, то они приведут к банкротству. На долгой конечно покрываются статистикой, если букмекер прошаренный.
Опять таки, спасибо что рассказали мне.
Я больше скажу, платят даже за 2 и более чтобы предотвратить риски что один накроется. Даже эти реалтайм фиды (которые идут от скаутах на матчах) не могут быть быстрее (в силу банальной сетевой задержки) чем человек который СИДИТ НА СТАДИОНЕ. Ставки "под гол" идут постоянно.
Это не так. 90% ставок в РФ — футбол. А 90% из них это три вида пари — 1х2, фора и тотал.
Все эти динамические пари они для показухи больше, что букмекер с широкой линией, денег там нет совсем.
Ещё раз спасибо что пытаетесь мне рассказать "как там у букмекеров", но я лучше знаю.
Полная чушь. Работал в этой сфере прям в мякотке букмекерства.
Люди заносят на фаворитов.
Возьмём Спартак-Реал. Какой бы кэф вы не поставили на Спартак, сумма денег (плечо) там будет на порядки меньшая чем баблище на Реале (гарантированный выигрыш даже с кэфом 1.1). И занесённые триллионы на Реал надо ОТДАТЬ с кэфом 1.1
Внимание вопрос, где тут выигрыш для букмекера? Ответ скажу за вас — тут чистый минус на грани банкроства.
В реале такие высоковероятные исходы отключают, чтобы выровнять "плечи".
Другой пример: играют Мухосранск-Задрищенск. Вялый матч, никто не может оценить силы этих дворовых команд, поэтому ставите 50/50 с небольшой маржой(т.е. кэфы будут 1.9 у обоих например) и тут внезапно на Мухосранск прилетает ставка в 10 лямов. Ваши действия как букмекера? Правильный ответ — НЕ принимать такую ставку, т.к. это явный договорняк и вы залетите на выплату почти 20 лямов.
Ещё пример. Кто-то сидит на стадионе и получает инфу о голевых моментах раньше логического ядра букмекера. Вот он видит что Месси вышел один на один с вратарём и пробивает. До гола ситуация на поле была равная, шансы на победу каждой команды были допустим тоже 50/50, после гола они очевидно изменятся, поэтому вы можете в последний момент поставить с ОЧЕНЬ выгодным кэфом за момент до его падения.
Короче, ещё многое можно рассказать, а многое не надо. Но главная мысль — не надо путать букмекерство и тотализатор.
В тотализаторе — собрал деньги с народа, выплатил другой половине за минусом маржи. И у нас в РФ тотализатор запрещён.
Чтобы заработать на букмекерстве, где тебя все пытаются обмануть, надо некисло работать с реалтайм данными и менеджментом рисков.
Противоречивые параграфы вижу я, но ладно :)
GHC у Хаскеля умеет компилировать как в натив, так и под LLVM
FSC в F# умеет компилировать только под CLR, но есть такая штука как .NET Native, которая сразу полученный код для CLR гонит в натив. Не пользовался за ненадобностью.
В JVM тоже есть способ гнать байткод в натив — Excelsior например.
Не буду скрывать, нативный бинарник Go получится крайне маленьким по размеру по сравнению с любым из вышеперечисленных, но это из-за скудности стандартной либы Go (и это слабо сказано), а не потому что там какие-то ядерные оптимизации происходят.
По поводу маргинальности — PHP и Питон тоже популярнее Haskell, F# и Clojure. Да и вообще всех ФП языков. Возможно даже вместе взятых.
Делает ли это Haskell, F# или Clojure плохими языками? Для тех кто не осилил их освоить — несомненно.
Смешались в кучу кони, люди.
Я понимаю что гоферам застилает глаза божественность Пайка, но неплохо мы обзнакомиться с теорией.
Языки, в которых в самом синтаксисе была селективная асинхронность с синхронным общением между легковесными тредами и корутинами:
Не говоря уж у тонне либ для языков:
Не поверите, везде одно и то же — собственный шедулер в юзер спейсе, n:m модель, легковесная абстракция над ОС тредами, синхронное общение (ченелы), селективная асинхронность.
Что нового привнёс Go? Убрал с гоферов необходимость учить Haskell, F# или кложу. Про CML я просто молчу, старый язык уж очень, хотя он до сих пор где-то в продакшне телекома юзается по слухам.
Поддерживающий только ОДНУ парадигму многозадачности (корутины) из коробки, и оберачивающий весь синтаксис на фоне в монадку Async, чтобы блокирующие вызовы байндились на континуейшн как будто это императивный код.
Любой нормальный язык даст вам на выбор другие парадигмы многозадачности: треды, корутины, фиберы. Монадки конечно же любые на выбор (без дженериков в Го их не сделать, поэтому захардкожена одна), на выбор вытесняющие или кооперативные юзер-спейс планировщики.
Это всё из Го убрали чтобы среднему гоферу не надо было мучаться проблемами выбора.
Я не уверен что до конца понимаю почему нормальный вывод типов нельзя подключить к C#
Ну если мы о C#, то да, никак.
А вот тот же H-M алгоритм же с бектреком. Все ограничения от литералов и функций он применяет взад) В этом например отличие алгоритма вывода в Scala от HM, она не умеет пропагировать типы по коду выше.
Бред. Алгоритмически он как раз выводим. Хиндли-Мильнер такое пережовывает на раз. Литерал инта есть? Есть. Значит это Int32.
Даже F# справляется.
Если написать так (аналог default из C#), но не указать тип, то заинферится object (справа, едва заметным серым цветом) и вывалится value restriction:
Если добавить присваивание от инта, то естественно алгоритм выведет тип за нас:
Лоу левел вещи (unmanaged и ко) действительно писать не так удобно как на C# (но возможно, и даже stackalloc есть, а недавно и Span завезли), но это даже для C# неидеоматичный код так-то! Для любителей поиграться с поинтерами в менеджд языке сойдёт.
А вот обычный ООП код (интерфейсы, пропертя, классы, абстракные фабрики фабрик синглтонов) писать на нём получается короче чем на C#. Потому что возможностей больше. У меня даже примеры есть)